INTERNs also welcome. Join a fast-growing, revenue-producing, world-changing, code-valuing startup in NYC. Bonus fun if you like sports, MongoDB, stats.
Non-technical jobs too: assistant/intern/do-it-all, and Head of Marketing.
as my own mother put it (here on the eve of our second): with one child, your world is turned upside down, but it's still essentially you're world they're living in.
iOS[objc]/Android[java/scala]/Python Programmers - New York, USA
GameChanger (http://gamechanger.io) builds mobile apps for scorekeeping at youth & amateur live sports events, aggregates that data and turns it into a stream of hyper-local media. We're under 2 years old, have a growing base of thousands of teams, great bizdev deals coming together, and have gotten some crazy press so far (http://gamechanger.io/press).
We've won awards for our apps, and are building out a real-time delivery platform and attacking a huge market. We're MongoDB + Tornado + Django + raw Python & 0MQ/ZMQ on the back end, Obj-C and Java on the mobile side.
Send github link / code sample & resume to jobs@gamechanger.io. Oh, and at least like sports a little.
Mmm, my first real project in Scheme was actually an HTML parser, but the spirit of it is the same. There's something enticing about an annoyingly complex spec that lets a beautiful language like Lisp shine.
But yes, I'm sure that Twisted wasn't in the shape it needed to be when FF started building this, and they've built up an alternative. That's never a bad thing.
Otherwise, there'd just be Apache... no nginx, no lighttpd, no fun!
It would be really nice if somebody could write a breakdown of these webservers for the uninitiated like myself. I'd like to know when to use which tool.
I started with a single hunchentoot instance running on SBCL on Win32 and I still hack on it about 16 hours a day. I deploy on a 30-instance hunchentoot farm with 4 lighttpds sittin on front of them.
Hunchentoot could either be a single-instance, one thread per request simpleton, or, given its flexible and well thoughtout architecture, an httpd development framework. The requests per second could also vary; the stock configuration is about 80r/s, but I am squeezing well over 2kr/s out of it. I have been tweaking it for the last 7 months or so and it just keeps getting better.
As a coder, I want a bug tracking system to work as a task list for me, and a repository for others. This is a hard dichotomy, but the ideal system would support it.
It's needs a command line interface or at least an open API, integration with Git, easy tagging & querying on tags, batch action tools that are easy (a-la GMail), and in-line editing / status-updates.
It also needs to deal well with a build process, and understand environments.
I've used every major relational database on the market, and views & stored-procedures being requirements are blanket generalizations that are arguable at best. Both of them are enterprise tools for working around stupid schemas and bad code.
Arguing that DBAs 'require' the complex features in the other relational database is like saying that Macs 'require' more complex interfaces so IT people can work with them.
views & stored-procedures being requirements are blanket generalizations that are arguable at best.
I hate to break it to you, but for any complex data representation you will have to make abstractions to work with it efficiently and consistently.
Both of them are enterprise tools for working around stupid schemas and bad code.
There are more complex systems out there than your blog. It doesn't have to even be near enterprisey before having solid schemas and relations are indispensable for working reliable and efficiently with your data.
Arguing that DBAs 'require' the complex features in the other relational database is like saying that Macs 'require' more complex interfaces so IT people can work with them.
I've heard worse analogies and will let this one slide. However your argument, in its essence, basically boils down to "lets just ditch databases, all their optimization features and just use unrelational, standalone files as records". You promote simplicity over rigidness and predictability, which is required for any processing and optimization.
If you for a second believe this naivé approach to data-access is going to give you better results in any non-trivial case, I'll challenge you to prove it. As for any trivial case: Performance doesn't matter, you might as well use XML.
It doesn't have to even be near enterprisey before having solid schemas and relations are indispensable...
Amen! Some operations necessary on our site would be so slow as to make it unusable were it not for stored procedures and multiple indices per table. It would also be incredibly slow were it not for a well-configured PostgreSQL install. And all we do is aggregate ticket listings.
I've seen people fight with barebones MySQL installs over even more data than I deal with and it's simply depressing. Sometimes "stupid schemas and bad code" have nothing to do with it; you just need to process a lot of damn data. And for that, if using an RDMS, you need one that is mature, rock solid, and has a sufficient feature stack.
Not all projects need complex data representations. I would suggest that few projects need a complex data representation rather they need an appropriate one. As to views, transactions, and stored procedures consider a large open messaging system like Twitter. While a traditional database could help with the users profiles and settings giving that up for a significant increase in speed might be a great trade off for them. Or they could mix several database systems using the best tool for the job.
The idea that all databases need all features is a mistake, once one free open source project has everything and the kitchen sink it's time to start solving other problems.
Trees, Pictures, Classes, Anything that varies on a per instance basis and can't be easily shoved into a fixed schema. There are plenty of things relational database suck at, are you implying otherwise?
* Front End Coder (Python, jQuery, Backbone, LESS)
* Back End Coder (Python, MongoDB, Redis, Fun)
* iOS/Android - (Obj-C/Java/Scala(?))
* DevOps - unix hacker
(NYC, baby)