spotman

Choosing a message queue can certainly be tricky.

Not a complete list, but you should consider:

a.) do you need persistence? some queues offer this, some do not. many systems can be configured in either mode. you might need persistence if the messages your processing are vital and shouldn't be missed in the case of a broker restart, for example. however if the messages are very volatile, then maybe persistence is overkill. Or possibly, the architecture your working with handles message loss somewhere else, so its not the message queues responsibility to worry about loss.

b.) do you need fault tolerance? some queues off this, some do not. just like persistence, its often something you can enable or disable. and like persistence, often queues can be setup so that while they might not be fault tolerant, the application that employs them is designed to work around queues going down.

c.) do you need high availability? fault tolerance and high availability are separate things. fault tolerance might just be a master falling back to a slave. high availability means this happening and there being no hiccup in service.

d.) performance. its something to consider, but your correct in thinking that this is not everything. but sometimes its worth considering. in one experiment I ran, Amazon SQS was about 40x slower than rabbitmq. This may or may not be worth the trade off for you, as products like SQS relieve the developer and operations a lot of responsibility, but if 10ms average queue time (or less) is important, forget SQS.

e.) client libraries. some queues have client libraries for every language in the sun. some only offer support for one. you would want to consider who and what will need to talk to the message queue, and if this is going to be made a nightmare if your using something very exotic or custom.

f.) creature comforts. some things come with nice rest api's, some come with web ui's, some come with only command line interfaces, and some come with none of that. Often things like ZeroMQ, Nanomsg, are put into these blogs and things comparing message queues. They really are not message queues in the traditional sense. They can only replace one after you've probably spent a considerable amount of time building tooling. For example, in zeromq there is no way to ask 'how many messages are pending in this queue' without writing that functionality yourself.

g.) queues-as-a-service. I mentioned Amazon SQS in point d, but they are something to consider if you don't want to run it yourself. Running a message queue can be easy, but running a message queue that is fault tolerant, highly available, deals with message loss/deliverability, and scales as your workload scales, can be an art form.

In summary, you should do your own research based on these needs and others I likely forgot. Sometimes its easiest to just pick a simple one, and then once you experience its shortcomings and learn more about your queue needs, the upgrade path will be much less mysterious.

I think its important to note that the title says most, and doesn't say 100% of the time unit tests are bad. It specifically mentions using them for critical functions/algorithms, or 'units of computation'.

But, he outlines some of the less useful parts about it, common mistakes, and my takeaway from the article really hits spot on with some poor experiences I have had with teams that get lost in unit testing, and it really can lower the code quality and simultaneously the velocity if not approached carefully.

Some key quotes from the article:

"If you find your testers splitting up functions to support the testing process, you’re destroying your system architecture and code comprehension along with it. Test at a coarser level of granularity."

This is all too common. Especially with inexperienced developers. Management requires 40, 60, 80, or 100% test coverage blindly, without thinking about whether it makes sense to test that particular part of the code, and furthermore doesn't take into account readability, or in my experience the pain of over-abstracting something. Little is worse when trying to debug a program, and dealing with over abstraction hell to the point where all you can read is the tests, and trying to read the source code has become entirely over complicated, all in the name of keeping the code in a format where its testable, at the cost of it being understandable.

Developers that have a lot of experience with system design and software architecture are in a much better place to write appropriate tests while still maintaining understandable source code, but if I had my choice between an over complicated codebase with 80% test coverage, or a more simple codebase with 0% test coverage, I would choose the simple codebase every time.

"There’s something really sloppy about this ‘fail fast’ culture in that it encourages throwing a bunch of pasta at the wall without thinking much... in part due to an over- confidence in the level of risk mitigation that unit tests are achieving."

In modern development shops that do a lot of TDD, the tests are relied on way too much. Testing of any sort is not a silver bullet. But you find people, even in pretty big, mainstream development shops of large internet properties, relying almost solely on this. Then they pass their 'finished work' over to operations to be deployed, and when something breaks because there was not a test that counted how many file descriptors were used, the developers are always so quick to say 'well, all the tests pass, so its an operations problem now'.

"However, many supposedly agile nerds put processes and JUnit ahead of individuals and interactions."

In the article he comments on how someone told him that debugging isn't what you do in front of a debugger (obviously debatable) but that its also when you're staring at your ceiling, or discussing the inner workings of a program or algorithm with a counterpart. This is so key, and this is why pair programming is often helpful if you get into a good rhythm with someone. Thinking intrinsically about how software works is the take away here, and all too often we see people rely on tests as a silver bullet and the end result can be code that is over complicated, over confident, and when deployed is an operational nightmare. These sort of things often have a giant net loss in revenue, due to the net loss in a teams velocity to ultimately produce code that works rapidly. When developers lean on tests less (but still employ them where it counts) you'll find easier to maintain code, written by people that will step up to the plate and be responsible for that code.

Obviously there are exceptions to this, and there are shops that have the right balance, and maintain high quality understandable code, while maintaining high velocity. Personally, in over 10 years of being in this industry, almost all examples of this that I have witnessed are open source projects that are peer reviewed.

Ah, interesting, did not realize that. Seeing people like yourself in the git stream made me think otherwise:)

And its even funnier that cyrus-imapd (which is what fastmail.fm runs, and contributes heavily too) is what I think (please correct me if wrong) is what is shipped with OSX Server. So the one IMAP server that apple likely uses for their own things, was potentially well tested, and its the one company thats running it has called them out, and now has to bite their words.

I use/run cyrus-imapd for years and have never had an issue with mail.app. But it is pretty frequent that I hear people with other imap providers (especially gmail) that have issues with it.

Unfortunately your experience is all too common. I personally interviewed two times at google. The first time I never made it to their offices, but made it through 4 phone interviews, that all went well. After I had gone through the 2nd phone interview, I had started interviewing at another company (well, I needed a job afterall). Within 3 weeks the new company had given me an offer. I meanwhile went to two more google interviews over the phone, and had been stalling on accepting the other job offer, because the prospect of working at google, was exciting. Well 2 more weeks went by, and finally the job offer at the new company was going to expire, so I had no choice but to take it. At this point I didn't see the point of continuing the interview with google, which my internal recruiter at google said would easily last 4 more weeks, as I had not been onsite yet.

Fast forward 3 years, and I had another poor interview experience with google. I flew up there this time, and got to interview in person. It was fun to see the google plex. I had 5 interviews in person scheduled. I felt like I ace'd 3 of them, 1 of them I did OK, and 1 I bombed. 2 days later google informed that that I was not a "culture fit".

I am not sure what the deal was. I felt like I had rapport with all of the interviewers, and I also had 2 internal recommendations. So, maybe that was some canned response way of saying no. Or maybe it was literal.

At any rate, I will never try to apply to google again, even though I too am contacted by a google recruiter no less than every 6 months. Sigh.

This is the coolest idea I have seen in a long time. I really really really wish you the best success!

I signed up for the beta, and can't wait to try and use it to hook into alerts. I look forward to calibrating ambient frequencies that correspond to things like message rates or queue sizes. Imagine if you had a teapot boiling sound if a queue backs up. Of course you want to go tend to that! Brilliant.

re: "compatible to another" - this is definitely not always the case. it certainly may be the intention, but is not always the case.

Random example: http://comments.gmane.org/gmane.comp.handhelds.phonegap/3631...

I work for a very popular cross platform mobile application (ios, blackberry, android), and we have dozens and dozens of test devices, a qa department just dedicated to finding differences between devices, and let me tell you that most of the time, special tweaks are required for android that are not required for ios. Surely this is hugely due to the fact that there is less variety in the ios world, but you simply wont find that "manufacturer xyz decided to implement this differently so now the developer must account for that".

Finally, in your analogy of adapting from Android->Android, is similar to adapting from say ios5->ios6. Having been through this several times now, I can tell you with confidence that the initial time of adapting is very similar with equally skilled developers, but the delta of "code complete" to "ready to ship" is much larger on android, due to all of the testing, double-checking, and edge cases. So in summary I would say that you do "adapt a little" with ios, but you end up adapting a lot more than a little for android, if you want to support more than a couple phones, in my opinion.

It can be hard to keep your head up in this situation, but, you should try. Just because this startup fails, don't let it effect you forever. Sure you have a right to be upset for now, but know that you have to move on.

In the way that you sold your idea to the investor (whether it was by way of having a product to show, or just fancy talking, or a combination of both), you will have to rise from the ashes and prepare to do it again.

You can, and probably should eventually frame this as experience, because thats exactly what it is. A lot of investors will look at this as a learning experience for you, if your able to keep yourself from being rattled out of the game.

The next time around, you will be able to look back on your experience, and hopefully make different choices that will help you stay at the edge of your seat.

Lastly, sometimes ideas just don't work, despite all your best efforts. Sometimes there is little you can do to change the course of history. Often, its a combination of both bad decisions, and being in the right place at the wrong time, or the wrong place at the right time.

Can anyone comment on the battery life for the iOS client in comparison to skype? I am a heavy skype user, and it doesn't seem like hipchat has a lot to offer than skype does not. Not to mention the inertia that skype has.

however, I would totally consider it, if i could keep it on my phone all day and not have 10% battery by 2pm.

also, curious, does it do group video chat, ala skype?

Ah, thanks. Mis-read that part of the article.

20mg is an awful high dose. The usual dosage is between 75-1000 micrograms. 1000 still being awful high. (and 20 milligrams, is a _lot_ more than that!) Wonder if its a typo, of it they are just going balls out.

I feel the same way. However I also live in California. I feel like its extremely accurate here, but it is also where it was essentially born. So it is not surprising it needs more work in other places. For everyone I know that lives here and uses it with normal habits, it seems to work just as good.

In time, and I suspect shorter than people estimate, the data quality will vastly improve. No software is perfect on the first release, and apples software is no exception. iTunes used to be glitchy in its early days, me.com was terrible when it first came out, but these issues have been rectified for the most part.

Google maps once led me 18 miles into the middle of nowhere for a dentist appointment. Sure, this error is fixed now, but the dentist office shows up correctly on maps. So It seems like here (in California) the data is better than it was when google maps was new.

I suspect by end of year, the majority of use-cases will work fine in many more places than california. Who knows, but if I were betting.. :)