Hacker Newsnew | comments | show | ask | jobs | submit | login

In the US: http://www.ecstasydata.org/

reply


There's also pillreports.com a basic review site to identify bad street pills

reply


Propeller, based in SF, is looking for great full-time developers to help change the way simple mobile apps are built. We're trying to do something legitimately new here, so first, some background: Right now, building a mobile app means:

1 (optional): Try to build a crappy version using non-native platform technologies like: HTML5, Titanium, PhoneGap, or some other solution that attempts to use or translate the web way (HTML/JS) to mobile.

2: Spend a lot of time and money building your mobile app from scratch using native API (Cocoa/Android)

Apart from the pain induced when you try to do (1) before (2), this is fine if you're building a complex or involved app that merits significant and dedicated time and money for development.

But, at Propeller, we think there is great demand for the ability to build simple mobile apps (which is why tools for (1) exist.) But, (1) sucks - it's not native, or it's native translated from web technologies, and becomes unnecessarily complicated. Method (2) works, but it's incredibly expensive because everything is being built from scratch.

HTML/JS was a great idea when shipping code was difficult, and users didn't want to install software. Everyone had a runtime already (the browser), and so simple applications were built on that platform. First just with HTML (the <form> element) and then HTML+JS for clients that were called "rich" but just needed to do things HTML forms couldn't do.

But taking this model and attempting to make it work on mobile is not only bad engineering, it's misguided! This model makes sense when you can't ship actual code to your users, but Apple changed all that by inventing[1] the App Store (straightforward) and getting users to trust it (really a big deal.) This removes the distribution problem. Users will install your software, so you don't need to target a legacy distribution stack that was originally designed for sharing documents and a really weird language with so many quirks a book title "The Good Parts" had to be written. It's bad engineering motivated by decisions which aren't relevant anymore. Building mobile applications on top of (or translated from) a legacy stack with so many workarounds, shims, libraries on top of libraries, Shadow DOMs, cross-browser compatibility, compile-to-JS, minification, XSS protections, and so on is just crazy.

HTML/JS on mobile will always suck and will always play catch-up because it's built on a legacy foundation. Hell, it sucks on the desktop now too. We put up with it because the alternative isn't feasible.

</rant>

But, there is another way! There are good ideas here.

Shipping code (and waiting for Apple to approve it) brings us back to the days when we had to release major versions and burn them to CDs and put them in boxes. It's un-agile. Developers love writing web apps because it's agile - they can change their application, deploy, and release their fix or feature very quickly. That's invaluable and should not be impossible on mobile. [2] So, our hypothesis is that there are a class of simple mobile apps whose behavior can be described declaratively using a simple JSON format that can be hosted statically, or delivered piecemeal as needed, or even generated dynamically a la a REST API. It could describe an app UI directly, and also how it interacts with a server API, and it could be rendered using native controls.

Think Web apps, but instead of a legacy stack that wasn't designed for application development, a simpler and more straightforward format uniquely suited and designed for modern Internet/Web applications, taking into consideration all of the things we've learned a modern Internet application needs.

Right now we're building (and shipping) sophisticated apps that are defined by our JSON format and rendered using 100% native controls on iOS and Android. We can update that JSON at any time to change the app on next launch. We can send down new JSON via an AJAX-like mechanism. We're iterating on the format/protocol, and shipping new version of the client. We're figuring stuff out around client-side views, realtime client<->server communication, data sync in general, and many other interesting things. There are enormous problems to be solved here, both engineering-wise and in API/Protocol/Architecture design.

YOU: are an interested hacker who isn't content to let people build shoddy applications on a gross legacy stack, or invest way too much time and money for things that really should be a lot easier. We're looking for someone who realizes all these pain points and isn't afraid to imagine how things should be done. Think: in 10 years, will people really be building new apps on HTML? No. Come help us design the stack of the future. Ideally, you have experience in iOS and Android, since that's our most pressing need right now and likely in the future.

US: a 3-person team (two co-founders and myself) trying to modernize (mobile) application development. We run Rails/Postgres/Sidekiq on the backend for the apps we host for our users, but our clients consume JSON so that's an implementation detail. In the future people can generate that JSON using any backend they want. Our iOS application is in Ruby (via RubyMotion, which has worked well for us) and some ObjC, and our Android client is in Java. We share some code between them (like our layout engine) and we want to share more. We've taken a seed round from some great investors[3]. We're very small still, so your impact would be immense.

EMAIL: jobs@usepropeller.com (I'm ben@usepropeller.com)

1: Yes, I remember Linspire. I'm using "invent" loosely here.

2: Apple doesn't let you actually ship code (or, technically speaking, an interpreter, you can ship JS) but many client-side interactions don't actually need to be re-implemented every time. HTML forms are an example: client-side interactivity without custom logic. There are many other interactions that can be abstracted this way, especially on mobile, where user interactions are more constrained, and especially for stuff that just updates the UI and can be solved using a Reactive/Data Flow approach.

3: http://techcrunch.com/2013/06/27/propeller-gets-1-25m-from-a...

-----


Maybe, the author wrote the two stories as interesting anchors around the principle in order to help you recall it when you need to. Maybe. Or something.

-----


You should ask yourself if the answer you're looking for will answer your question.

-----


Minor correction: Coda isn't our CEO.

-----


I gave an example in the paragraph right above that. There are many more examples and testimonials from paying customers at the link I posted. I'm happy to answer any more questions.

-----


What example? I read it again, and I really don't see any "info on what makes us different than facebook/irc/campfire/status.net"

As I already said https://www.yammer.com/product/index does give me some idea of how Yammer is different.

-----


We don't throw this figure around lightly. Certainly some companies use Yammer more than others, but every company uses Yammer differently. Some companies even pay us for it.

-----


Your reply is a non-statement that sounds like it came straight from the marketing/PR department.

What percentage of Fortune 500 companies have at least five users who posted something on Yammer in the last two weeks?

-----


Yammer is hiring engineers in SF and London, and a bunch of other non-engineering positions in London/NYC/AUS/elsewhere. Full jobs listing at https://www.yammer.com/jobs

Yammer is basically a social network for the enterprise, but Yammer isn't just where you talk about work, it's increasingly where you do work.

Large corporations are really inefficient and hierarchical and Dilbert-y, and we build software that treats every employee as an empowered human being. We have a success-story video on our site from Supervalu, a large retail store chain in the US, and their CTO tells a story about how Yammer literally changed the way they do business. In the old world, store managers would report their intelligence up the managerial chain, the upper management would try to synthesize everything, and 3 months later a "report" would be issued that told everyone how to best try to do their jobs. After Yammer, store managers would just talk to each other over Yammer, learn directly what was successful and what wasn't, and as a side effect, let the upper management gain invaluable visibility into day-to-day operations. When we say Yammer "breaks down silos" and "enables horizontal communication", this is what we mean. Sure, Yammer is just like Facebook, but we're so much more than that. Corporations don't share cat pictures, they turn into efficient business machines.

Supervalu testimonial video: https://www.yammer.com/customers In fact, Supervalu isn't the only company that has changed the way they work due to Yammer. We have tons of examples at that link. Yammer is used by 85% of the Fortune 500.

Yammer is expanding. We just raised an 85MM round, reflecting a valuation that puts on right up there in the enterprise software space. We're growing quickly and we need strong capable solid engineers to help us. We have an excellent technical platform but we need to scale more. This is where you come in. We're looking for engineers of all stripes, be it Ruby/Rails, JS/Node, Java/Scala, Obj-C/iOS/Android, or other. Again, full list at https://www.yammer.com/jobs

If you're remotely interested in solving real engineering problems at scale, for a serious application, I urge you to get in touch. My email is bkudria@yammer-inc.com, and you can ask me any questions about Yammer that you'd like.

-----


To give you an example of the sort of stuff we do behind the scenes at Yammer, here's what my team has shipped:

* a realtime message delivery service which handles hundreds of thousands of concurrent clients

* an activity stream data store serving just shy of a billion requests a day

* a distributed database serving well over a billion requests a day over tens of terabytes of data with ~10ms response times at the 99th percentile

* a realtime search indexing pipeline, complete with a denormalized entity store, index replication and an autocompletion service

* a data export service which basically performs a diff of the state of millions of business objects and sends it out as a streaming ZIP file

* a user account synchronization service which handles streaming JSON dumps of companies' LDAP/AD server data

* an affinity prediction service which provides ranking of arbitrary objects based on past interactions (e.g., who you're most likely to CC on a message)

* an OAuth2 token service for 4MM users

* a collection service for the user events pipeline of our analytics system, handling hundreds of thousands of user events a second

* plus a grip of open-source libraries

And this is a team of seven people (now). The other teams at Yammer ship just as much as we do.

-----


... and besides interesting and challenging work you get to work with developers like codahale!

-----


That would be true only if no one was harmed by your profiteering.

-----


Also on BusinessInsider: http://www.businessinsider.com/how-yammer-should-have-respon...

-----

More

Applications are open for YC Summer 2015

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: