tannerburson

Drizly | Boston, MA | https://drizly.com | Full Time

We demand convenience in all facets of life, Uber with transportation or OpenTable with reservations, the liquor store should not be different. A Drizly delivery brings the liquor store to you in 30-60 minutes, right from your smartphone.

We have several openings for Senior Engineers on the Backend, Frontend and Mobile.

Apply at: https://jobs.lever.co/drizly or email me tanner@drizly.com and mention Hacker News.

Mention HackerNews in your submission

For giggles I spent an hour this evening and added support for Disque to the pluggable system I help maintain [0].

Things I can say: the ruby disque library isn't really fleshed out yet. It's alpha, so that's fine, but it's got a ways to go. For example, it doesn't directly expose ACKJOB as a command. The server is equally alpha, things like HELP don't do anything yet, and some options on some commands appear broken. But hey, it was a fun way to spend an hour.

[0]https://github.com/tannerburson/chore-disque.

> Here's the idea: companies that rely on Ruby contribute money to a pool. The board of directors > authorizes spending money out of that pool. They authorize this money towards supporting core > Ruby infrastructure and projects. All of this is through a non-profit, so it's tax deductible for > everyone.

That summary should appear somewhere on the website, as it includes the core of what you're doing much more succinctly than anything I found clicking through the links.

Thanks for the details, and thanks for working to improve the Ruby community!

As someone who relies heavily on the Ruby ecosystem to do my job day-to-day, this is really interesting. But I can't tell from the site what exactly it's doing. Are the membership "dues" going to fund an individual (André?) or a team to work on this full-time? Part-Time? Can I influence with my membership which projects my money is allocated towards? Will the accounting for the money be published within the "membership"?

As it's presented, I have too many questions to even begin to be able to put this in front of my organization and feel comfortable that what I'm pitching provides good value for the money spent.

  "Think of YAML as a human readable Marshal."

That's what people missed. YAML is a marshaling format, full stop. The Ruby community has to absorb this idea, and quickly, because YAML is everywhere.

So you're wanting to reinvent XMPP?

So a guy hacks github, he's a hero. A guy hacks a bunch of media organizations, and he's a villain. I really don't understand the groupthink these days.

How is one of these okay, and the other not?

I wrote a post on my blog about that a little less than a year ago. I'm sure some things have improved, but in general, I've moved on.

http://tannerburson.com/2011/04/03/Thoughts-on-Appcelerator-...

I agree, the original piece was a decent explanation of how to refactor some helper type code into a more Presenter like model. But he completely skipped out on the question of why it's a useful thing, and when it's a good fit. If that post had been by DHH or another Rails core member, we'd see it instantly picked up into the current cargo-cult trend of the month.

That said, I do appreciate Steve's work on finding ways outside of "the one true path" to simplify Ruby code, and hope he'll continue writing these sorts of things going forward. If nothing else, the discussion surrounding the technique and it's alternatives is extremely worthwhile.

You're a bit off here. Appcelerator doesn't actually compile ANY javascript to native code. They expose a device specific API via a proxy/bridge system they call Kroll. They have a bunch of ObjC code that they then front with their Kroll Proxy. They also have a small shim between their JS interpreter, and Kroll on the other side.

So in effect any app you run on Appcelerator is still bound to the characteristics of their chosen JS interpreter, AND the characteristics of their proxy, AND lastly the performance of their native API.

It does provide a relatively simple path, to getting relatively simple apps up and running with native widgets but not inherently native performance.

Disclaimer: I've only ever dug into the iOS source, I can't swear this is 100% valid on other platforms.

I appreciate your comment, and it's great that you're reaching out to the developers using your platform. I'm excited to try out the debugging features of Titanium Studio, and hopefully it's more transparent in the steps it's taking to build an application as well.

Your second paragraph rings a bit hollow though. I'm sure you all are committed to growing the platform, I'm sure you're making investments. What software company isn't trying to move things forward? But as a user, I frankly don't care about how much better things will be. I just want to get things done, and the current state of your product makes that difficult. Worse than that, the current track-record of development (as witnessed by may comments here!) doesn't show a lot of progress.

I earnestly look forward to seeing improvements in the near future, as I have an application to deploy and support!

I completely agree with your last sentence. I don't begrudge them opportunities to monetize their platform, but I can't help but be frustrated at watching new functionality being added on top of piles of bugs.

My biggest beefs are: the fact that the build system is a complete black box that fails without a good indicator of what it takes to fix it, and inconsistencies in how events are handled, 'swipe' and 'scroll' being prime examples of events that either don't work as expected, or work in unexpected ways.

I haven't bought support, so I can only speculate based on their community forum, and public bug tracker. With that out of the way, unless paid support gets custom code deployed to them fixing core platform problems, I don't see it as being a solution.

In it's current state I couldn't recommend Titanium to anyone. I hope it continues to improve, and get better, as both the idea and implementation have a ton of positives, it's just almost unusable right now for anything big enough to really see the benefits in the multi-platform support.

I agree, PhoneGap today looks much better than it did when I started this project on Titanium about 6 months ago. I definitely wish I'd gone that route in retrospect.

I haven't found on device performance to be too terrible for latest gen iPod Touch and iPhone 4. It's definitely inconsistent in places though.

You're dead right on debugging, it's pretty much guess and check, all the way through. Painful puts it mildly.

Move out of the city. In the more rural areas that isn't as true. It's definitely trending in that direction, but there are still a lot of kids who grow up with parents in skilled trades who pick up a lot of those skills growing up. Combine that with high schools that have legitimate trades programs, and there's at least a much better opportunity.

There is nothing (that I'm aware of) stopping you from setting up your own Open ID provider that used the method you described for authentication. The downside of course is that it's Open ID, which means it's pretty much only useful at places you don't need it.

It's funny you should say that... http://www.playlookit.com/how-to-play-lookit#j-mobileapps

But what's insecure about the marketing pages being sent in the clear?

It's common practice to setup a subdomain for your secure communications so that you aren't having to send images, javascript and public pages through HTTPS. Load times are part of the reason, but the other is that it takes more resources on the server end too.

I'd love to hear your actual reasoning on this though.

Your experience pretty well mirrors my own.

My first several jobs I was thrown into the deep end and expected to find my own way back up. Typically about the time I'd get a solid handle on what I needed to do, the job turned into something I was much less interested in.

You should put some contact info in your HN profile. As a fellow OK Hacker, I'm always looking for other interested locals to chat with! (And if you work at the main interworks office, we're in the same town as well).

That was exactly what I was getting at. It's also not a matter of "is it technically possible" but (s)he claims that it's a popular choice. I don't buy it, but would love to be proven wrong.

Really? Can you cite a source for this rather absurd claim?

This looks to be a summary of a summary of the study linked at the end. For a more instructive look at the survey, check out http://www.fastcompany.com/magazine/145/next-tech-five-steps... .

I agree, good company, good people, but this is total link spam. There is not real content, nothing to discuss, nothing. It's probably nothing but votes from people who work there too, which is sad.

I'll agree with your latter point, he does seem a bit sensational in his claim that the device will be physically useless in less than 24 months. But I disagree with your first argument.

You're correct that he omits that they have removed DRM from their music, but not their videos. And I think you can safely argue the point that if Apple had started out with iTunes without DRM that they never would have made it off the launchpad. He also specifically used the term "entertainment industry", which is still true. Apple still uses restrictive DRM on it's videos, as well as it's i(Phone|Pad|Pod Touch) products. The latter are definitely marketed as "entertainment devices".

You have to go a step farther, if you agree that the model is flawed, don't buy the device, and tell others why you've made that decision. Which is exactly what Corey is proposing (and doing).

We won't see groundswell against this kind of thing, unless we help to create it by educating potential customers.

In fact, Apple's fear of the customer (which leads to their love of DRM) runs so deep that they avoid any built-in peripherals that might allow side-loading of content and applications. The only hardware interface to the device is completely proprietary and requires a license to access.

The device is conceived from the ground up with the idea that Apple must control all aspects of it's use. Any features that might lessen that control are thrown to the side.

I have a hard time watching the evolution of computing go from relatively open platform that sparked my interest as a young person, to locked down DRM restricted devices.

His point is the exact opposite of what you're saying. He's alluding to the fact that Apple's application review process has as much, or more, to do with your success than whether your users love the app or not. If Apple decides to reject you, or reject a needed update, or even just delay it for an extraordinary amount of time, you're out of business.

This is the exact opposite of a web app, or a linux app, or even a desktop OSX app. You write it, you distribute it, and it's on you to make it successful.