Se há apenas duas possibilidades, uso if/else apenas como ternário:
return foo === null
? fizz
: buzz| # Cut/Trim video | |
| ffmpeg -ss 5 -i input.mp4 -to 10 output.mp4 | |
| # Video to gif | |
| ffmpeg -ss 61.0 -t 2.5 -i <input> -filter_complex "[0:v] fps=12,scale=w=480:h=-1,split [a][b];[a] palettegen=stats_mode=single [p];[b][p] paletteuse=new=1" output.gif | |
| # thumbnail | |
| ffmpeg -i mov_bbb.mp4 -ss 00:00:03 -r 1 -s 1280x720 -f image2 thumb_mov.jpeg | |
| #text in video |
| 'use strict'; | |
| const assert = require('node:assert'); | |
| const fs = require('node:fs/promises'); | |
| const DATA_HOME_URL = 'https://storage.googleapis.com/access-logs-summaries-nodejs/index.html'; | |
| const DATA_FILE_PATH = 'data.json'; | |
| const DATA_CSV_PATH = 'data.csv'; | |
| const DATA_CSV_SEVEN_DAY_PATH = 'data-seven-day-avg.csv'; | |
| const LINES = ['14', '16', '18', '19', '20']; | |
| async function main() { |
| use std::sync::{Arc, Mutex}; | |
| use std::sync::Condvar; | |
| use std::thread; | |
| use std::collections::HashMap; | |
| use std::time::Duration; | |
| struct Node<T> { | |
| value: T, | |
| next: Option<Arc<Mutex<Node<T>>>>, | |
| previous: Option<Arc<Mutex<Node<T>>>>, |
| # | |
| # .gitignore for any Java app =) | |
| # | |
| # https://gist.github.com/boaglio/8c76e6cf795afa0ee04f2faf3ea97a56 | |
| # | |
| # Gradle | |
| .gradle/ | |
| **/build/ | |
| build/ |
| package main | |
| import ( | |
| "fmt" | |
| "os" | |
| "time" | |
| ) | |
| func timer() { | |
| // Cria um ticker, um relógio que retorna um channel com o tempo atual, |
| /* Qual a diferença entre 'var', 'let' e 'const'? | |
| * | |
| * Todas essas keywords servem para declarar variáveis, mas cada uma delas tem nuances diferentes. | |
| * / | |
| /* Cada bloco de código nesta página é independente e deve ser executado em um ambiente JS limpo, | |
| * sem variáveis globais declaradas. | |
| * | |
| * Comentários de bloco separam diferentes blocos de código. | |
| */ |
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
In order to design a piece of software we need to “design” the team that is going to produce it.
A camada domain provê as regras e as unidades de negócio usadas na aplicação. Nesta camada estão os Services que são consumidos pelos BLoCs/PageControllers da camada app, as Entities e os contratos dos repositórios de dados, cuja implementação concreta fica na camada data.
Hoje um colaborador da lista sobre Teste de Software [DFTestes] (http://br.groups.yahoo.com/group/DFTestes/) perguntou em uma thread sobre PhantomJS qual era a difernça entre Smoke Test e Acceptance Test. Ai resolvi responder. Como a lista é somente de acesso aos usuários registrados, estou colocando um resumo, na minha ótica, a diferença entre eles:
Dentro de um contexto ágil nós temos uma separação clara do que é smoke test e o que é teste de aceitação.
Smoke Test: conjunto de testes (bem menor do que o conjunto de teste de aceitaçaõ, que vai configurar posteriormente em uma regressão) com o intuito de validar se os pontos maisimportantes da aplicação continuam funcionando após as alterações.
Teste de Aceitação: São os testes funcionais que conhecemos. Em um contexto ágil eles são chamados de aceitação ao invés de funcional, pela ótica que adotamos a estes testes, que vão tanto validar a aplicação funcionalmente como validar também da ótica de um usuário (fazer uma venda completa, por exemplo). Este