tannerburson's comments

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 [email protected] 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.