This - if you have to fetch data from or output data to outside of the AWS ecosystem, the 512mb /tmp limit pushes you into the additional (relative) complexity of having to run on Fargate pretty quickly. Just had to deal with this for a content ingest job involving pulling a couple GB of data from an FTP server, processing it and pushing it into an RDS database on an hourly basis. Would have been super simple if the file was on S3 already.
I live in LA and travel to the Bay for work frequently. I can walk to a Metro station from my house in Highland Park in 10 minutes and be at Union Station in 13 minutes. If I could spend 3 hours on the train to SF from Union instead of driving to Burbank, arriving an hour before my flight, and then spending an hour on a plane, I would do it every time.
But the COST of the interest is in year 0 dollars. I may be buying Cokes in 2015 dollars, but if the price is set in 1900 dollars I'm getting a shitload more Cokes.
But I'm buying a $500k house in 2015 dollars. If we peg the appreciation of the house only to the long-term inflation average of 3.22% over the next 30 years and I purchase the house today at current 30-year fixed rates of 4.09%, I'm going to pay a total of $868,713 over the lifetime of the loan for something which will be worth $1,178,775 (in 2045 dollars). I will have made $310,062 in 2045 dollars, while also having a place to live the whole time.
Even if we factor in other costs during that period beyond loan servicing, such as insurance, taxes, utility repairs and maintenance it seems unlikely I will have LOST money in the process.
It's not a terribly GOOD investment, but it's not a financially asinine choice either.
Poverty may be a necessary condition for "startup" success in the somewhat narrow definition of a startup common in our industry, but the idea that it's necessary for BUSINESS success is total nonsense, which is a useful thing to remember when you're feeling artificially burdened by being over 30 and middle class(!) The bulk of new wealth in human history has been created by people who already have some modicum of existing wealth, or access to it.
This is 4 blocks from me. I went to check it out but there was a line of around 150 people out the door and I bailed since I wasn't willing to invest the 90 minutes in line.
I'm as much a grammar-and-spelling nazi as anyone and can quote you chapter and verse the difference between it's and its, your and you're, effect and affect - but considering I've misused every one of these within the last week in email and sundry comments scattered across the interwebs, I'd argue this is not much more than "sometimes we all type fast and fuck up" ;)
Anyone want to speculate on how many years it will be till we see a similar announcement on a trial program for e-hailing self-driving Uber cars in SF? The future is a cool place to live.
Pet projects? Absolutely not, although never a minus. ;) More: are you engaged with the community enough to be aware of the current ecosystem, (handwaving) "best practices", libraries/gems, etc. If someone claims to have been building Rails apps for 5 years, but has never heard of Devise and Carrierwave, it's definitely a red flag for me. If you're trying to get a job on the Google search team and can't whiteboard a quicksort it's going to be an equivalent red flag for them. I'm trying to attract a specific type of developers for a specific kind of programming work where caring about this kind of stuff is useful as a signaling factor to me.
It's not about requiring everyone who works for us to be a 23 year old with no family or life who spends every night hacking on shit, just about a baseline standard for community engagement. Lack of Github account with some level of activity (even if that's just starred repos, forks, etc) is a pretty strong indication someone wouldn't meet that level of engagement, and so wouldn't be a good match.
Depends on what stack you're working with, and the associated broad engineering culture. I haven't hired anyone who didn't have a Github repo in 2 years, out of 18+ FTEs and contractors - but we're a Rails/Scala/node shop building fancy web apps for startups. Not having a huge OSS track record is fine, but not having a Github account at all would be kinda weird these days. If we were doing embedded systems stuff or financial modeling software or game development, probably a lot less relevant. The "show us your Github, not your resume" line in a lot of job posts is more about the specific engineering culture in a particular kind of startup development, not a hard and fast rule for every software firm everywhere.
That said, if you're a Rails developer and you don't have a Github account, I'm still probably not going to read your resume.
Compassion is a great one, a trait I feel like we don't spend enough time talking about as an element of success. I've worked with many extremely talented, genuinely bright people whose business skills suffered because of a lack of compassion and empathy: for their users, coworkers, or people they generally (and probably correctly) considered less intelligent than themselves. Making a conscious and genuine effort to understand someone else's position and needs will get you MUCH further than dogmatic self-righteousness - even if you really are right. ;)
Saw this post this evening: http://nickoneill.com/building-a-plane-on-the-runway/ - "pivoting" is a meaningful startup pattern when it means "variations on a theme", informed by data and quantitative customer discovery, rather than the the "am I building an iOS app to manage your pet rock collection, or Airbnb for dogs?" flailing which too often hides behind the label.
Like "agile", "lean startup" can mean pretty much... anything the person using the phrase wants it to mean.
With agile, sometimes the word is used to justify a rigid excess of ceremony, or as a firewall for lazy developers to hide behind to avoid being responsive to non-engineering members of the organization, or as an unrealistic attempt to turn software development into an assembly line of a bunch of jack-of-all-trades "cross-functional" team members ("specialists? we don't need no stinkin' specialists!"). But the core observation of agile is that writing huge planning documents and spending weeks perfecting PRDs and GANTT charts at the outset of an engineering project and then using these to derive project timelines and costs is inefficient, and that "delivery to QA" 3 months over an arbitrary schedule and 70% over an arbitrary budget is a classic failure mode for this approach to planning. Instead, a focus on building self-organizing, trusted teams who are delivering working software frequently and iteratively, and gathering customer feedback and adjusting "the plan" after each delivered increment of software can result in both happier developers AND happier customers.
Similarly, "lean startup" CAN be synonymous with "changing my mind about what business I'm in and 'pivoting' every 3 weeks", but really the core observation could be summarized as "build things people want", with all these new-fangled buzzword-y tools like customer development interviews, business model canvases and even "pivoting" as a means to this end. While the Ries book is useful, Steve Blank's The Startup Owner's Manual (http://www.amazon.com/The-Startup-Owners-Manual-Step-By-Step...) is phenomenal and the ideas there certainly "transfer very well outside the world of tech start-ups."
Take what works, leave what doesn't, ignore the hype and think critically.
I'm fairly sure that the federal case against Aaron is still being litigated (http://en.wikipedia.org/wiki/Aaron_Swartz#JSTOR), which means that he almost certainly can't discuss details publicly.
When I hear the "shouldn't we solve poverty and climate change here first?" argument about space exploration, I feel it's useful to remember that almost all improvement in the human condition throughout history is directly attributable to advances in human technology grounded in investment in exploration and basic research. Spending on science, technology development and exploration are the real "trickle down economics". I don't think it has to be an either-or proposition. ;)
I don't understand why more tech recruiters don't ruthlessly specialize and laser-focus on building a deep understanding of a particular niche when matching candidates and employers.
I'm CTO of a web and mobile development shop with about 20 employees. Finding good frontend developers is REALLY hard - to be a great frontend guy these days, working on modern web apps, you need to have strong engineering chops, with knowledge of the html5 apis, css3 and serious JS experience, including an understanding of memory and performance management in large frontend-heavy apps; ideally have worked on a couple of medium size apps with 5-7 person teams; probably have at least some exposure to the current JS framework scene; ideally (for our stack) have experience with preprocessors like sass or stylus and coffeescript; have good design sense and the ability to work in a collaborative feedback loop with a designer, etc etc. It's a really cross-functional role. There's a lot more people who "know HTML and CSS" but have never worked on serious apps, or have solid JS chops but can't produce design with reasonable fidelity to save their lives.
A relationship with a recruiter who understood this "candidate profile" and could bring me people who would be a good fit, not just resumes with "HTML", "CSS", "Javascript" and "5 years of experience" on them, would be worth its weight in gold.
In my opinion probably a more viable approach for testing consumer-oriented ideas (e.g. "Daycare Review Service") than B2B products (e.g "Lesson Scheduling for Music Teachers"), but some really useful and actionable stuff here.
The famous "everything that can be invented has been invented" quote attributed to Charles H. Duel, a late 19th-century commissioner of the US Patent Office, is apocryphal (http://www.patentlyo.com/patent/2011/01/tracing-the-quote-ev...) but remains a comically potent response to this sort of short-sighted bullshit.
There will always be new problems to solve. There will always be better solutions invented to existing problems. And solving problems experienced by a lot of people, and solving them well, will always be worth a lot of money.
I run a 20-person webapp design and development consultancy, with employees all over the US and no central office. Group communication is a constant problem for us: we use Campfire rooms for most project communication, but frequently have to drop into Skype for ad-hoc video calls. I wind up in Google Chat several times a day with employees and clients as well. Campfire is great for realtime-ish team conversations, but if you want to ask a question like "hey, anyone want to go in on a house for SXSW?" you're probably better off sending an email if you want everyone to see it and have a chance to respond. We keep a lot of company docs in Google Docs, stuff which would really be more useful in the company wiki we don't have setup currently. I could go on, but the gist is that our communication tools for project teams, the company, clients, and 1-on-1 conversations are pretty fragmented.
Theoretically Yammer should solve this problem. It doesn't. We've experimented with it in the past, and it's a poor fit in a thousand tiny ways. We're a bunch of geeks living all over the country designing and building software products, not a division at Big Co.
Are you going to be releasing an events API in the near future? I've had an app idea banging around for a few months that this API would be perfect for.