TomFrost's comments

This article digs on the flattened dependency model like it's a huge weakness of Bower, but this is the _entire point_ of Bower.

You include two models that both depend on two different versions of jQuery. NPM wouldn't complain at all, Browserify would happily package both dependencies up, and now your users are downloading jQuery twice to view your page.

Bower, conversely, raises a red flag right away, and lets you determine what should be done here in the event that the package definition doesn't contain enough info to sort this out automatically. Its goal is to make your client code as minimal as possible.

Feature, not bug.

1. Node.js is (for the most part) single-threaded; that's its draw. It's not trying to be a swiss army knife, and if your use case requires a threaded language then Node.js certainly isn't the tool for that job. But it might find a useful place in your toolbox for other tasks.

2. require() is part of the CommonJS spec, and how it physically works is dependent on the implementation. You point out that Node's implementation doesn't work well in the browser, but Node itself does not work in the browser so that point is moot. I agree that it might be interesting to load remote modules in Node, but keeping that operation synchronous does simplify the language quite a bit.

3. You can also map modules to public or private git repositories in the package.json, as long as the private key used during npm install has access. If the git repo has tags, a tag can be specified in the git uri as well. Private npm repos are the superior way to distribute private modules with wider access, but I think this is handled fairly cleanly already.

Similar library for (Node|io).js, with exponential backoff and randomness: https://github.com/TomFrost/node-attempt

Coincidentally, I had a demo call with Sumo today. I was very impressed, except for one point that makes Splunk the clear winner at the moment: I can send structured logs to Splunk and it automatically finds the keys and allows me to query on them immediately.

Meaning, I can send: 2015-02-02 01:00:00 event="Product sold" price=5

And with zero configuration in Splunk, I can now query: event="Product *" price>2 | stats sum(price)

And in the next iteration of my app, I could add 30 more key/value pairs to that message and could query on the rest of them just the same, no configuration. It makes development incredibly rapid to be able to instantly report on any metric anyone on my team logs out, debug-related or otherwise, without having to maintain some master list of every key in every log message in every service we write.

I was floored in my Sumo call today when I was told that wasn't the case in that product yet. It seems like such a basic feature-- and is why many products have switched entirely to JSON-based logs. Have you discovered a workaround, or find that to be as cumbersome as I'm anticipating?

I'm sorry to say I was once heavily involved in this. I am Kyek, or "Kytek" as the article misspelled. Among other things, I wrote and maintained Appulo.us, and the quote at the end of the article is mine.

While many called BS on the whole "we do it for trials" aspect -- and who can blame them? -- that is, in fact, how this all started. A small group of people on IRC and a forum, who figured out how astonishingly easy it was to dump the entire unencrypted executable from RAM, who shared apps among each other because those little $1-5 purchases added up to a lot when the apps proved misrepresented and worthless. Back then, it was far more common that reviews were gamed and descriptions were blatantly false, and 'lite' versions were quite rare.

I eventually left when that dynamic became an obvious foregone conclusion, and only a very small handful of us continued to purchase the apps that we intended to keep. Frustratingly enough, those who remained and admitted behind closed doors that they were in it for the free apps kept up that mantra, so it became far more of a joke than a meaningful message. I'd have loved to see Apple innovate and find a way to offer developers an easy method of providing time or usage-limited trials, but their response was to dump money into legal rather than R&D.

This article is really nothing new; nothing has changed much from a standpoint of the piracy or Apple's reaction to it since Appulous launched, except Apple's methods are more streamlined and so are the pirates'. However, this article makes the same misleading assumption that all the articles of the past made: They assume that every pirated app is a missed sale.

When you report that 92% of your application's installs are pirated copies, the implication is strong that you've missed out on 92% of sales. That's simply not the case. Many people -- and let's be realistic with the demographic, many young teens who may not even have access to purchase apps on their own -- install these apps just because they're free. If piracy weren't as easily available, I have no doubt that the 92% figure would shrink in direct proportion to the number of installs. Reporting otherwise is wholly inaccurate, and exaggerates the impact that this community has had. And I say that as someone who hasn't supported the community and in fact has spoken out against it for years.

Appulous was an education for me. It taught me about running seriously high-traffic sites, and query optimization and caching algorithms unlike anything I thought I'd ever dig into. Over the past five years that's transported me professionally into a great position where I get to coach dev teams through that kind of work daily, and continue innovating and learning about scalable design. As a vehicle for rapid improvement in my trade, it was a fantastic opportunity. But as for the the lasting impact my contributions have had on the topic and on indie developers, I'm deeply regretful, and disappointed. Apptrackr's proved that if it weren't me, it would have been someone else; it's just a shame that the agenda has switched so obviously from pushing for a better app store to enabling single-tap piracy -- regardless of the _actual_ impact that might have on sales.

Clearly, the next logical step is to make a love song for developers.

This is worth a little more elaboration, I think. If you compile the iTerm2 version of tmux provided on the iTerm2 website (a merge of the fork into tmux proper is pending), then you can link iTerm2 natively to a tmux session.

This means that the iTerm2 window size is the tmux window size; tabs in iTerm2 are tabs in tmux. Horizontal and vertical window splits in iTerm2 are the same in tmux too. And all of this is bound to the GUI, so resizing/reordering panes with your mouse makes the proper modifications in tmux. And because this is a 1:1 mapping of functionality, others using the same native integration will see tabs and split panes get added and removed in real time, as someone on another machine does it.

It's still in early stages and definitely not bug-free, but this is absolutely the best multiplexing experience I've found. Unfortunately, because this is specifically for iTerm2 right now, it's not cross-platform.

We've seen floods of these "What you should have done if your application was interrupted Friday night" articles, but a common theme is to leave out the fact that many of these sites require synchronized data storage, which Amazon doesn't support between regions. If your organization is shelling out the money for something like Riak, Oracle, or the mess necessary to support such an architecture though the likes of MySQL or Postgres, this is all well and good (save for the data transfer overhead costs).

If your application is architected to use SimpleDB, DynamoDB, SQS, or even RDS, these simple "You should have been using Route 53 and multiple regions" articles get increasingly frustrating. Most applications simply aren't elementary enough to fit into that boilerplate structure, and getting around that fact either requires switching away from Amazon's managed database services (lots of money) or writing synchronizing scripts that play nicely with your stack and launching them on additional servers (lots of money and lots of resources).

While ideally I'd like to see Amazon release some sort of feature for multi-region sync, it would be interesting to see how the tried-and-true multi-region businesses have approached this problem.

I can't agree -- among a younger demographic in coastal regions (speaking in terms of the US here), sure, maybe. You need to know what a QR code is, you need to know what app can read them, you have to download that app, and if you're not the type of person that these things come naturally too, you have to learn how to use that app.

That process just isn't biddable for wider demographics. Outside of my tech-savvy group of friends and co-workers, I'm not sure I know anyone with either the understanding or the patience to use them. Until it's far more common for this to be a built-in and automatic feature in mobile devices, I'd be blown away if it ever caught on.

http://picturesofpeoplescanningqrcodes.tumblr.com/

> * Word-addressed memory will make string processing interesting to implement. Maybe in space, everyone uses UTF-16.

Everyone in Minecraft, too -- almost. The string encoding in Minecraft's protocol spec is UCS-2, just a sneeze away from UTF-16. It seems Notch has a soft-spot for large encodings. It makes sense from a calculation and lookup perspective, but I wonder if the increased bandwidth and storage of 16-bit blocks has a measurable impact.