nesquena

Fair enough, I've adjusted this to be more clear now.

Fair enough

I've updated the guide to reflect your valid points here.

Did this ever get resolved?

Looks cool!

I like your style and your sentiment here. We are committed to exactly the ideals you outlined here. Tim and I are both startup founders and very product-minded engineers. Our program is less about "whipping together a cheesy iPhone app" and more about helping people learn design, product development, et al. Every engineer is put onto a team which involves planning, designing and building a product idea of their choice with plenty of mentorship along the way. We have big plans to expand curriculum in all sorts of directions. Mobile happens to be in demand and highly sought after in the valley but this is bigger than iOS training.

We are big fans of Hack Reactor and similar programs. I think they fill a real need for aspiring engineers who want to jump into the field.

The key differences for us are we are very focused on existing experienced engineers that want to learn new technologies in a hands-on accelerated way amongst peers. We offer our courses in the evenings around a job schedule and the courses are free of charge. Our business depends on helping those interested find jobs they love. See http://pandodaily.com/2013/08/26/job-recruiting-in-silicon-v... for more information.

"Highest quality" is a complicated thing to define but suffice to say it is in part about creating ultra high quality. We provide detailed videos, extensive wikis, hands-on projects, open-source and closed-source libraries, and extensive mentorship. We also have a process for selection of our candidates that involves a phone screen and a short in-person interview to assess background and commitment to the program.

This article might help clarify: http://pandodaily.com/2013/08/26/job-recruiting-in-silicon-v... we see this as an opportunity to fix talent development and placement in a big way. Put it this way: consider the difference between an "engineering referral" from two experienced engineers who have spent weeks with each carefully selected candidate versus other models today. We have spent quite a bit of time exploring the sustainability of this. All I ask is you reserve judgement, we have a lot of ideas of how we can make this work.

That's right, Tim and I (CodePath founders) are both startup-minded software engineers with backgrounds in product development and web and mobile development stacks.

brain looks pretty cool and I also noticed she not only works at mozilla but also regularly speaks at conferences. Weird how judging a person's competence based on looking at a single for fun open source project may not be a great idea.

What a great idea to go around calling other people stupid for creating personal open-source projects that they enjoy using, mocking their competence and treating them as if they should go away because they aren't as good as you. What a productive use of a developer's time.

Yeah I mean it's OK to make judgements and think or believe whatever you want. Maybe even tell how a friend or two how silly something seems to you while hanging out. It's a different thing to being a dick to someone publicly on the internet for trying to contribute positively to open-source.

Glad to hear rabl is working well in conjunction with rails-api. Haven't had a chance to try that combination yet, mostly been using rabl alongside Sinatra, Grape and Padrino.

Definitely, thanks for your feedback. Will be bringing up redis in the next post. Redis has some messaging functionality baked right in and can be a good solution as seen with https://github.com/defunkt/resque in Ruby as well. ZeroMQ is also an important technology to understand in the context of this discussion.

Interesting, thanks for sharing the links. I think building your own message queue is sometimes the only way to get things working exactly as you might want. For people looking for a highly configurable framework for building a tailored MQ, be sure to check out http://www.zeromq.org/ as a basis.

Yes beanstalkd has solid persistence support now in later versions. You can use the “-b” option, and beanstalkd will write all jobs to a binlog. If the power goes out, you can restart beanstalkd with the same option and it will recover the contents of the log.

I agree and if polling was the only consideration then this would mitigate the issue. Admittedly I didn't cover this as much in my article but there's also a lot of other flexibility afforded by a good message queue around delivery strategies, consumption strategies, error handling, etc that you would have to do much more manually and painfully trying to shoehorn it into a database (even a good one). I am not saying PostgreSQL notify commands are not useful for certain tasks, just encouraging people to understand the tools available and pick the right one for the job.

Thanks for your feedback, I appreciate the thoughtful response. I actually agree that generalized message queues can often be complex and perhaps even unnecessary when dealing with asynchronous processing at a small scale depending on your needs.

I think the important thing is to understand your requirements, the volume of jobs, etc. In my series, I also plan to introduce much simpler lighter work queues that are a perfect medium between a 'heavy duty' generalized message queue and trying to wedge a queue into a database.

But as with everything, people should evaluate the available options for themselves. My goal is just to provide people with a framework for understanding the tradeoffs.

Thanks! That's exactly why I am writing this series. I plan to take people slowly through everything about asynchronous processing, message queues, handling job processing, etc. Message queues are underused in modern web apps, and I think also not understood as well as they should be. Planning to include plenty of diagrams along the way to help with that.

It is an awesome piece of software. If you like it, I would love for you to check out https://github.com/nesquena/backburner which is a resque inspired project powered by beanstalkd. There is a great sinatra admin tool as well https://github.com/denniskuczynski/beanstalkd_view

I think part of it is a marketing and documentation issue. I have been working to help get beanstalk into a better place specifically around ruby tooling and overall documentation. Check out https://github.com/nesquena/backburner for my solution for a 'resque' inspired DSL for using beanstalkd. We are using it in multiple projects. Also, I have been working to improve the ruby beanstalk client. Expect more news soon.

Just want to add a quick comment about our goals for gitdocs. Obviously this was never intended to be a 'dropbox-killer', in fact at Miso we actually use both. Dropbox for videos, large binary files, business and legal files.

Instead we use gitdocs for storing our "docs": Task lists, wiki, planning, collaborative design, note taking, code snippets et al. And the gitdocs web front-end (http://imgur.com/eaTTY) is optimized for that since it renders wiki pages (formatted markdown/textile), has full code syntax highlighting, file search, revision history and a rich text editor.

You may want to check out our our DIY dropbox attempt: https://github.com/bazaarlabs/gitdocs

Automatic uploading, web front-end and versioning.

Would be curious how you guys would compare this library to gitdocs, our DIY dropbox attempt: https://github.com/bazaarlabs/gitdocs

Ours includes a full web front-end, versioning, 'cloud' (git) storage, and relatively easy install. Oh, unix cross-platform too (with some windows kinks being worked out).

Not a bad idea at all. Gui wrappers for osx, and later linux and windows would be an awesome way to allow this to be used by less tech saavy people in the future. I suspect an osx cocoa wrapper would be pretty easy to write. We also plan to build out a web front-end that allows users to browse,edit,and upload files from right within their browser.

But in this case, we are storing your files in a simple git repo defined by you. A git repo you could store on say github or bitbucket of which both are git hosts that are not going away anytime soon. In a way, this is just replacing a hosted dropbox with a hosted git repo should you choose to use it that way.

I think graceful file conflict resolution will be an essential part of gitdocs and we will work to handle these edge cases as best as we can. Thanks for bringing it up.

We plan to address those issues, namely cross-platform support and easy install, and of course striving to keep things as simple as possible.

Yeah we agree regarding route generation being important. We came up with a decent solution to it for Renee, let us know what you think: http://reneerb.com/route-generation and time will tell but we think the combination of clearer routes, leaner code and url generation makes renee a fun alternative.

Yeah this is an early release. I can think of several ways to enhance the DSL even more with ideas similar to this to cleanup common cases.