[
- SOLID
- GoF - Design Patterns
- Clean Architecture
- Linguagem onipresente do DDD
- Testes de unidade, integração e funcionalidade
Executa todos os testes
$ npm testExecuta somente os testes unitarios(*.spec.ts ) qua ainda não foram comitados. Esse comando é utilizado somente em momento de desenvolvimento por usamos o TDD como tecnica de desenvolvimento.
$ npm run test:unit$ npm run test:e2eEstabelecer limites entre coisas que importa e que não importa não é tarefa fácil. O endpoint não importa para as regras de negócio, então deve haver um limite entre eles. Banco de dados não importa para endpoint então deve haver um limite entre eles, bancos de dados não importa para as regras de negócio, então deve haver um limite entre eles. Framework não importa para nossa solução, então ...
Alguns de vocês podem rejeitar algumas dessas afirmações, especialmente aqueles que aprenderam que bancos de dados estão relacionados com as regras de negócio e que o framework xpto com nossa aplicação. Mas acredito que essa crença está equivocada, nossa solução deve ser desenvolvida guiada pelas regras de negócio e não pelas regras de banco de dados, framework e bibliotecas. E porque isso? Simples, porque não temos controle sobre eles, esse recurso foi desenvolvido por um terceiro e até certo ponto pode nos atender, quando deixar de fazer sentido para aplicação ela deve ser fácil de ser substituída.
No nosso exemplo as dependências externas são os módulos em vermelho.
Por motivo de segurança nosso sistema deve criptografar as senha do usuário antes de salvar banco de dados e para poder fazer a autenticação desse usuário posteriormente, não importa como isso vai ser feito, o que me importa é que seja feito da melhor forma possível, com base nessa regra de negócio eu posso estabelecer um contrato entre o biblioteca que faz a criptografia e a minha aplicação. Essa regra se aplica a todas as dependencias externa ao meu projeto. Isso no permite concentrar nas regras de negócio e evita tomar decisões prematuras MongoDb, Casandra ou DynamoDb. MySQL, Oracle ou PostgreSQL. GraphQL, SOAP ou Rest. E mesmo que a decisão que tomamos deixe de fazer sentido ele deve ser facil de ser altera, gerando o mínimo de impacto possivel.
You can also:
- Import and save files from GitHub, Dropbox, Google Drive and One Drive
- Drag and drop markdown and HTML files into Dillinger
- Export documents as Markdown, HTML and PDF
Markdown is a lightweight markup language based on the formatting conventions that people naturally use in email. As John Gruber writes on the Markdown site
The overriding design goal for Markdown's formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it's been marked up with tags or formatting instructions.
This text you see here is actually written in Markdown! To get a feel for Markdown's syntax, type some text into the left window and watch the results in the right.
Dillinger uses a number of open source projects to work properly:
- AngularJS - HTML enhanced for web apps!
- Ace Editor - awesome web-based text editor
- markdown-it - Markdown parser done right. Fast and easy to extend.
- Twitter Bootstrap - great UI boilerplate for modern web apps
- node.js - evented I/O for the backend
- Express - fast node.js network app framework @tjholowaychuk
- Gulp - the streaming build system
- Breakdance - HTML to Markdown converter
- jQuery - duh
And of course Dillinger itself is open source with a public repository on GitHub.
Dillinger requires Node.js v4+ to run.
Install the dependencies and devDependencies and start the server.
$ cd dillinger
$ npm install -d
$ node appFor production environments...
$ npm install --production
$ NODE_ENV=production node appDillinger is currently extended with the following plugins. Instructions on how to use them in your own application are linked below.
| Plugin | README |
|---|---|
| Dropbox | plugins/dropbox/README.md |
| GitHub | plugins/github/README.md |
| Google Drive | plugins/googledrive/README.md |
| OneDrive | plugins/onedrive/README.md |
| Medium | plugins/medium/README.md |
| Google Analytics | plugins/googleanalytics/README.md |
Want to contribute? Great!
Dillinger uses Gulp + Webpack for fast developing. Make a change in your file and instantaneously see your updates!
Open your favorite Terminal and run these commands.
First Tab:
$ node appSecond Tab:
$ gulp watch(optional) Third:
$ karma testFor production release:
$ gulp build --prodGenerating pre-built zip archives for distribution:
$ gulp build dist --prodDillinger is very easy to install and deploy in a Docker container.
By default, the Docker will expose port 8080, so change this within the Dockerfile if necessary. When ready, simply use the Dockerfile to build the image.
cd dillinger
docker build -t joemccann/dillinger:${package.json.version} .This will create the dillinger image and pull in the necessary dependencies. Be sure to swap out ${package.json.version} with the actual version of Dillinger.
Once done, run the Docker image and map the port to whatever you wish on your host. In this example, we simply map port 8000 of the host to port 8080 of the Docker (or whatever port was exposed in the Dockerfile):
docker run -d -p 8000:8080 --restart="always" <youruser>/dillinger:${package.json.version}Verify the deployment by navigating to your server address in your preferred browser.
127.0.0.1:8000See KUBERNETES.md
- Write MORE Tests
- Add Night Mode
MIT
Free Software, Hell Yeah!