Uns meses atrás fiz um screencast pra dar um overview do sistema de cache do Django pra uns amigos, o tempo passou e esqueci de compartilhar aqui também.
Como não tem muito material tentei mostrar alguns exemplos dos tipos diferentes de uso do cache.
I know we are living in the era of zero-downtime but, given my website user base and the fact that it’s really simple and small, I thought an old school “maintenance page” would be enough for me at the moment.
My deployment process is executed by a single command, so it’s quite stable and fast.
For the sake of completeness, I would talk a bit about my deployment process. Continuar lendo
I have a project where there’s a model with a profile imagem field. This field is required.
I did not want to maintain an image file in the repository just for tests, so I decided to research other solutions.
I’ve created a helper method that returns an ImageField, which then I use at the object’s creation with the model’s manager:
English version here.
No meu projeto, tenho um modelo que possui uma imagem de perfil. Esse campo é de preenchimento obrigatório.
Como eu não queria manter uma imagem no repositório só para teste, resolvi pesquisar outras soluções.
Eu criei um método auxiliar para criar um ImageField que uso quando crio um objeto diretamente pelo manager do modelo:
So last month I decided to try something different, I decided to try to commit something on GitHub every day for 30 days.
Few days ago I was at my 30th day. In those 30 days I’ve committed around 45 times.
I’ve made a series of small improvements on an open source website I maintain, solved a few exercises from Google’s Python Class, and closed 3 simple bugs for Kuma, the project behind the Mozilla Developer Network.
Three months ago I quitted my job as a Java developer and move out of desktop development for the first time.
Currently, I’m working as a web developer, both backend and frontend, at a university in my hometown. A lot of new things to learn, a environment completely new.
In this project, we are a team of two developers. The application is almost 15 years old and the source code is a disaster. All the developers that used to work in this project left the company almost at the same time.
When I decide to accept the job, our initial idea was to modernize the frontend stack, that was besides from using old technologies and have a completely messy code; and to restructure the backend code to better separate the responsibilities.
Três meses atrás sai do meu trabalho como desenvolvedor Java e abandonei o desenvolvimento desktop pela primeira vez.
Atualmente, trabalho como desenvolvedor web, back-end e front-end, em uma universidade da minha cidade. Muita coisa nova, um ambiente completamente diferente.
Nesse projeto somos um time de duas pessoas, a aplicação tem quase 15 anos de existência e o código é simplesmente um desastre.
Os integrantes da antiga equipe de desenvolvimento saíram da empresa praticamente ao mesmo tempo.
Assim que entrei para preencher a vaga, nossa ideia inicial era de modernizar o front-end, que, além de contar com tecnologias antigas, tem um código completamente desorganizado; e de reestruturar o código back-end para separar melhor as responsabilidades.
Abrir uma conexão com o PostgreSQL não é propriamente a definição da palavra lento, mas é uma coisa que pode ser facilmente otimizada.
Se você usa o banco de dados em um servidor diferente, ou mesmo se usa localmente, abrir uma nova conexão pode demorar alguns milissegundos.
Eu uso o Opbeat para monitorar a performance do meu projeto, observando o breakdown do tempo gasto em cada camada da aplicação, dá pra observar que mesmo 27.5ms representam, na minha Home, 23% do tempo de chamada da requisição.
De uns tempos pra cá, comecei a desenvolver um site usando Django, tem alguns meses que estou desenvolvendo no meu tempo livre e recentemente resolvi colocar ele online de verdade.
Como o site vai ter bastante upload de arquivo por parte do usuário queria um jeito simples de fazer backup disso.
Vi um monte de jeito que o pessoal estava usando, até que vi o headless Dropbox e gostei. Seguindo essa linha resolvi dar uma pesquisada melhor nisso e fiz usando ele também.
Por um tempo eu usei paralelamente três VCS, o Git, o Mercurial e o SVN, o último basicamente por causa do trabalho. De um tempo pra cá tenho tentado focar mais em uma única coisa e direcionar meus estudos, por assim dizer.
E na questão de VCS a escolha foi o Git. O Git surgiu para substituir o VCS usado anteriormente no desenvolvimento do Linux, que era proprietário.
Tanto o Git quanto o Mercurial, eu usava principalmente em meus projetos particulares, dessa maneira eu acabei não tendo a necessidade de usar alguns recursos, mas como resolvi focar em somente uma ferramenta, achei que seria uma boa dar uma lida melhor sobre o Git. Continuar lendo
