That moment when you realise your Universally Unique Identifier... isn't.
@stevejalim – YJ Tech Lead
We like UUIDs at YJ. One use of them we're particularly fond of is sticking specific yet meaning-free labels on objects, so we don't have to worry about exposing 'walkable' integer PKs or human-readable usernames or any of that awkward stuff.
As such, we've used our own UUIDField . . .
Solving the case of the missing objects
tl;dr Beware of race conditions when using async queues and accessing data which may not have been committed on the main process.
Whenever we have to update an external system (pushing out data to out CRM system, notifications to HipChat, sending emails, that sort of thing) we send the data asynchronously by queueing up a function with . . .
tl;dr Heroku’s filesystem is ephemeral, so be careful when running the collectstatic command - it doesn’t necessarily do what you think it does..
Our current production asset delivery setup looks like this:
- Run grunt locally to generate static files
- Commit changes to repo
- Push to Heroku
collectstaticto push staticfiles to S3
- Configure . . .
Does anyone round here know SQL any more?
We recently hired someone to help us with some data analysis and reporting requirements. We're not really big enough to claim that what we needed was a Data Scientist, but that is effectively what we were looking for. And as is our wont, we created a simple test for applicants, designed to show some ability to extract meaning from data . . .
BitBucket to Codeship to Heroku
Disclaimer: I'm a Continuous Deployment sceptic. I've always been suspicious of people who automatically deploy code to their live environment, and still am. Seems risky to me. See this article for more details on the difference between continuous delivery and deployment.
I've blogged before about our deployment tools, which . . .
Deploy to a specific Heroku environment based on committer with a custom script
(tl;dr this is a precursor of a longer post on continuous deployment at YunoJuno, and deals specifically with custom Codeship deployments.)
In addition to hosting our dev, uat (staging) and live environments on Heroku, we now have separate Heroku environments (apps) for each developer on the team. We used to allow developers to push their . . .
Putting it all together with virtualenv (and foreman)
(This is the final (possibly) article in a series of four, and follows on from Docker services. Code from this series of articles is available on Github as yunojuno/trifecta, and the VM is available on Atlas, the Vagrant box repository hosted by Hashicorp.)
If you've been following this series to date, you will now have a vanilla Vagrant . . .