A Brief Summary
After a hackathon a few months back, we were joking about creating an easy way to take the data we’d painstakingly parsed from PDFs, word documents, and XML files, and “translate” it back into a format that government agencies are used to. Many of us have been shell-shocked in dealing with PDFs from government agencies, which are often scanned documents, off kilter and photocopied many times over. Fundamentally, they’re very difficult to pry information out of. For the OpenGov Foundation’s April Fools’ prank, we created Govify.org, a tool to convert plain text into truly ugly PDFs.
Waldo just posted The State Decoded 0.8 Release. This is a *huge* update that we’ve spent the last few months working on. 577 changed files, 127,076 additions, 5,123 deletions. That’s a lot of code.
There are a few pieces I would have liked to squeeze into this update, like abstracting the XML import to make JSON importing more user-friendly, and cleaning up the admin system – but those will come for the 1.0 release. Which is pretty close on the horizon.
In the meantime, check out the 0.8 release of State Decoded on Github!
As a web developer, the greater part of my job is not creating new apps, but hacking together disparate software packages into Frankensteinian amalgamations that (supposedly) work together seamlessly. This is universally a headache, as the original authors tend to write code thinking that their app is the only one that will be installed. WordPress, Vanilla, and Interspire’s Email Marketer are some of the worst offenders that I struggle with regularly.
When coding your own brilliant application, there are a few simple things you can do to avoid potential collisions and headaches later, especially if anyone else will be using your code. Here are a few areas to pay attention to. (more…)
So, one us pilots was trying to use Doctrine migrations to update a database on one of our servers. However, Doctrine was sternly refusing to use the correct database, as configured in the
database.yml file. As it turns out, using Symfony from the command line skips the usual route through the
/web/yourapplication.php file (e.g.
frontend.php). As a result, the environment is not properly set when reading the
database team management app.yml file, and instead the last database connection specified is used. Lame. The trick is to specify the environment from the command line, so this file (and the other config files) do what they’re supposed to:
symfony doctrine:migrate --env=staging frontend 119
where “staging” is whatever the environment is you want to use (to match the name in the
The Doctrine manual is really, really confusing in places. If you want to do something as simple as updating a record, the examples suggest that you use
Doctrine_Query::create(). This doesn’t make a lot of sense, because we only want to manipulate the model, we shouldn’t have to even look at a query. (more…)