jeremydw's comments

Feedback: It's kind of hard to understand this statement. Your product is basically a client-side API that allows my application to use your API to integrate with a third-party storage service. So "cloud storage will be free forever" means your API is free to use forever for someone else's cloud storage? Presumably you make the code available to the customer to use and then restrict usage/distribution with a license?

A friend of mine is on the team for Kloudless (https://developers.kloudless.com/). I haven't actually used it, but the marketing material tells of the same value prop as your project. Have any quick summary of the differences?

While this doesn't directly pertain to your comment, perhaps it's somewhat related to onboarding with GAE...

I've been developing on GAE since it was released in 2008 and recently became "Google Cloud Platform Certified".

I'm considering offering a "Google App Engine for Startups" class/workshop (at something like General Assembly). The class would primarily include details about the platform's architecture and best practices for building high-scalability apps (like, say, Snapchat) so your app can "scale without thinking twice." Do you think there'd be some interest in a class like this?

Perhaps it's Netflix Open Connect? (http://oc.nflxvideo.net/docs/OpenConnect-Deployment-Guide.pd..., https://signup.netflix.com/openconnect)

I'm building Grow and the Grow SDK (http://growsdk.org) which has a lot of overlap with Statamic (file-based, content in Markdown, YAML things).

One of our tag lines is "develop everywhere, deploy anywhere" – as in, sites are file-based and can be developed locally or in the cloud on our web service. Grow can deploy to a variety of servers (S3, GCS, Dropbox, etc.).

The project's not quite ready for use yet but the SDK will be released as an open source project under the MIT License.

Someone submitted my introductory blog post about Grow on HN a few months ago: https://news.ycombinator.com/item?id=6562182 – Right now you can sign up for the mailing list, and when a developer preview is ready I'll send out updates. :) I hope to have something ready in a few weeks, actually.

I just downloaded it to Glass and tried it out. The UI is nice, and very simple. You say "OK Glass, translate this" and then you point your face (the camera) at some text (there's a bounding box on the display that you put the text into).

You need to hold your head still, and then the software expands the bounding box to the full size of the screen. Everything I've described so far happens very quickly, and then slowly some of the words on the screen are translated and replaced in place. The lighting in my room is not very bright, and so far I've been unable to get full sentences to translate (just words, and just for a moment until I move my head a little), but I suspect it'd work better in high contrast situations (out in the sun, block text, etc.)

Tapping the side of Glass lets you switch between to/from English/Spanish.

Edit: Last thing, IMO, the largest downside to the UX right now is that when you move your face (even a tiny bit) the in-place translation disappears and you need to hold your face steady again to get the translation to appear. This would obviously make it pretty difficult to use in a real world situation (like, if you're walking outside – you'd need to stop and hold very still to translate a sign) but it's still super cool.

OP here. I totally agree with your statement in that it's becoming easier and easier for single developers to build (and launch) something cool.

I suppose I must have glanced over this when I wrote the post, but I'm definitely targeting Grow towards producing content-heavy informational marketing web sites, blogs, portfolios, landing pages, personal sites, corporate information pages, marketing campaigns, etc.

In other words, Grow is great for teams that want to produce and manage stuff like the marketing content you see on https://stripe.com/, http://about.pinterest.com/, http://www.apple.com/mac/, http://www.google.com/think/, etc. I wouldn't recommend using Grow to build your actual product. :)

Often times, coordinating the launch of your marketing content with the launch of your product is tricky, and that's another thing I aim to solve.

Ghost is super cool and I love the UI, but I also find that having a persistent database limits some of the portability. And, depending on what's in the database, it might mean that developers can't use their favorite tools (like Sublime Text, etc.) to author content, develop and design templates, etc.

This is a bit of a shameless plug, but I figure it's relevant to this topic. I just put up blog post introducing my new project, Grow (http://about.grow.io/blog/all-i-want-to-do-is-build-a-web-si...). Grow overlaps with Ghost in some ways, but attempts to be a full-fledged, modern file-based CMS and is not designed just for blogs alone. I've been following all the replies in this thread to get a better idea on what people are looking for, and I think I've nailed it.

Basically, the way I've architected Grow is the whole system is file-based: content is stored in Markdown or YAML files, templates are stored as Jinja2 templates, separate from the content.

When you start up a Grow server for development, essentially what amounts to a super lightweight in-memory index is created from the file structure, and that allows your site to be generated (including pages that leverage complicated queries or access content through taxonomies).

This design keeps everything incredibly portable (zero-configuration development AND zero-configuration deployment) – which is one of the values that I hold to be very important. Anyway, the project is still super young (and my blog post is light on technical details, but I'm working on it), so I'm interested in getting any early feedback.

I posted about this last night, but this discussion is significantly more relevant to my new project, so I figured I would jump in and post again.

This is awesome because it's actually exactly something I'm building – a portable, open source, file-based CMS with a NoSQL document store, backed by Git, hosted in the cloud for social management/deployment, also runs locally. Eventually I'm planning to add easy blogging features for "non-techies" though my initial target audience is definitely professional, interactive web site developers who work with a big team.

If anyone is deeply interested in this space, I would love to learn more about your requirements and share more about my project so I can develop based on real user needs. You can also check out a data sheet I put together at http://grow.io. :)

Shameless plug: Solving high-quality web site production (for a multi-person dev team, including non-developer personas such as designers, content writers, reviewers, translators, etc.) is actually part of a new project I'm working on (http://grow.io). If you (or any other reader) has an immediate need for this type of product/app, I'd love to talk to you to learn more about your requirements (and share more about my project).

Mountain View at Google

My team is hiring a Python/JavaScript developer to work on internal developer tools on a small tools and infrastructure team at our HQ in Mountain View. Specifically, we are building tools responsible for the production and maintenance of thousands of Google's websites.

Apply via the following application (the role in the JD isn't exactly the one I described, so please mention you saw this post on news.ycombinator.com to get your application routed to the right place!): http://www.google.com/about/jobs/locations/mountain-view/eng...

---

Requirements:

* Strong Python knowledge.

* Experience building web applications and web services (RESTful).

* Experience with NoSQL databases.

* Experience with HTML/CSS/JavaScript.

* Excellent attention to detail and knowledge of web application design best practices.

* Excellent leadership and organizational skills.

* Excellent ability to communicate with diverse groups of users and developers.

Preferred:

* Experience with App Engine (and Django).

* Familiarity with content management systems and/or web site production tools and related processes.

---

As a member of our tools team, you will work on a small team of web developers and collaborate with marketing and engineering to develop the web applications and systems that create, manage, and serve Google's web sites.

You will be working on all aspects of our internal site development tools: developing systems and services that support the main application, working with developers to spec out and design new features, and ensuring that our systems are stable and fast. You will communicate with our users (webmasters, web developers, designers, localization, marketing, product management, etc.) to come up with creative ways to enable them to build and manage thousands of high-quality web pages.

You will work independently but also take direction and participate in a close-knit team-based environment. We regularly write and review design docs for major and minor features and have open discussions about application design. We release our primary application daily and have high test coverage and code health.

You must be passionate about the web and be excited about enabling Google to build and create the absolute best web sites possible!