_lex

Ok - it looks like commenters are unable to see why he calls this "passive income".

It's because although the work is done by hand, he can eventually (in like a month) hand it off to his own employee or contractor for them to do for a fraction of the profits.

Starting it up himself allows him to formularize the entire business, build a following and keep costs low in the beginning. He probably also plans to start creating similar email lists for other verticals with high levels of contractor work - so not just developers, but also designers, devops etc.

If you read between the lines, you can see where he's going with this; it can absolutely be a passive income stream, and based on his traction, it may replace his need to work.

Edit: To commenters below - Most successful businesses eventually hire someone to run them w/o much intervention from the investors/founders. He can do the same.

Missing from these job posts is "WHat's in it for me": There's largely no mention of compensation in any form on most of thes e job postings. Most don't even mention the office culture or expectations beyond the fact that the company's virtual and they want good engineers.

Given android's upward trending market share dominance, android-first will probably be the default in the next year, with android-only becoming the norm in 3-5 years. As the article points out - you've got to follow the numbers. At that point, iOS will be treated similarly to mac os - there will be groups of people who love and swear by it, but while they'll be rich, they won't be the mainstream market.

This so so mean. I've got 6 more times left. Now I'm buying ticket home for xmas.

It's likely that Dropbox probably makes way, way more money from enterprise than from it's consumer business.

Best case scenario you still have network trips going out to the service, so it's still not a great solution UNLESS the caching was done by your webapp - which is what I spoke about at the end of my comment above.

Unless this works w/o adding network roundtrips on each request, it's not a great idea.

This will get you penalized for having a website that takes forever to load. This is what happens:

Googlebot requests page -> your webapp detects googlebot -> you call remote service and request that they crawl your website -> they request the page from you -> you return the regular page, with js that modifies it's look and feel -> the remote service returns the final html and css to your webapp -> your webapp returns the final html and css to Googlebot. That's gonna be just murder on your loadtimes.

If this must be done, for static pages, it should be done by grunt during build time, not by a remote service. For dynamic content, it's best to do the phantomjs rendering locally, and on an hourly (or so) schedule, since it doesn't really matter if googlebot has the latest version of your content.

Or perhaps I'm mistaken and the node-module actually calls the service hourly or so and caches results on app so it doesn't actually call the service during googlebot crawls. If that's the case, I take back my objections, but I'd recommend updating the website to say as much.

What's up with this in the footer? "Financing: Government of the United States · Control: CIA and NSA"

1. You're not running your db on node. It's unlikely that your data will disappear if it turns out node has a bug -> the failure case is much more serious for mongo on docker.

2. You run the even versions of node (noted as stable) in production - they've literally set things up so there's an acceptable way to run node in production.

3. You're showing people how to make a production environment on a system who's creators do NOT want it to be in production. Sounds like a bad idea to me.

Docker is awesome, but specifically NOT ready for production.

From Docker's website "we make a point of saying that we’re not production ready".http://blog.docker.io/2013/08/getting-to-docker-1-0/

While I love your enthusiasm, I worry that you'll mislead others into thinking that its a good idea to replicate your setup and run something important.

I dunno - my parents would never stop using such a service - it's easier than googling your problem, and they find new tech problems on a weekly basis, and they aren't great at pattern matching to solve those new problems. God help them if the device auto updates into software that looks any different....

I agree that it's a response to poor engagement, but if that's the case, I think they're trying to solve a usability problem by throwing people at it. Apple's biggest selling point for the last 4 years was "It doesn't come with a manual because it's so simple". Amazon seems to have given up on simple, and on manuals - their equivalent phrase would be "it's so complex that we've hired people to help you use it, 24/7".

I think that although this service is a small step forward for currently confused users, it's likely a huge leap backwards, because it'll leave those people confused forever, and dependent on the "amazon lady" to use their tablet for them. On the surface, this seems too ridiculously obvious, so I have to imagine that they've got an awesome game plan that is yet to be revealed.

I'm confused about the mayday feature - is it free, and is it included on the $139 device? I can easily see my parents burning through $139 in tech support over a single weekend, just to get things setup. I can also see lonely people calling just to see someone and talk, and presenting fake issues that they need help with. Finally, I can see mayday leading to the sort of technological illiteracy that you see in a household when one person is responsible for all IT support - the other person winds up barely able to log into their own accounts because someone else always solves their problems for them.

"Docker itself is intentionally limited: when you start a container, you’re allowed to run only a single command, and that’s all. "

- Not exactly true, you can launch a shell in that one command, in interactive mode, so you're then able to run as many commands in that shell as you'd like.

I read the article. You need to read my comment.

It's about the fact that food often DOES go bad by the sell-by date, and that Trader Joe - where this guy got his experience - has changed their policies to aggressively push older, effectively near-expired goods on customers. That's what I hate, and it's pretty relevant.

That would be totally fine if this was Safeway or somewhere else that isn't selling fresh goods that go bad quickly. This isn't the case for things like bread and cheese at Trader Joe's - those things go bad just after their sell by dates. I'd agree that it wasn't unusual or shady if it wasn't a significant departure from their standard practices - I've shopped at TJs for years, and this change is fairly recent.

The Safeway experience is agonizing, though I'm sure it must be profitable for them at least in the short term. I just avoid them now, even though they have things I just can't find at TJs.

Exactly. Most people aren't realizing that my frustration is with the extremes of the rotation - food shouldn't be going bad/ have a use-by date that is the day after you buy it.

Trader Joe's obviously has had a significant change of policy recently to reduce losses to perishables, and it's foisting those losses on customers. I hate it.

I'd agree with you, if the buffer had a sensible cutoff. The cutoff is currently "tomorrow" - so you'll buy stuff who's useby date is before you've even opened it. Sucks.

I HATE this. I previously shopped at Trader Joe's with confidence - I knew I wasn't being gouged on price, so I generally ignored prices. I knew the food was good, so I could turn my brain off and just buy whatever I fancied. However, maybe 7 months ago, I started to notice that I was buying expired or nearly expired things from Trader Joes - bread that would go bad the next day (got mouldy), cheese with mold, etc. It was super irritating, and I would never remember to return those things so I'd wind up eating the cost.

I eventually realized that for perishable goods, they put the new stuff in the back of the shelves, so now I just head for the back of the shelf when I need to buy perishables there. This sucks for me, since buying at TJs used to be a stress-free experience, and now I check the 'use-by' dates on everything.

I actually flirted with shopping at Walmart (the one on San Antonio), but even though the prices are lower, the checkout lines are crazy at peak times, which is when I shop.

I also checked out Safeway, but they do a pricing technique that I call "Price Warfare". They randomly advertise products on heavy discount, and get you to incorporate those products as defaults in your shopping habits, then they switch their discounts to other products. This means that I've wound up paying $7 for basic icecream (which usually costs around $3:50). They also like to prominently display expensive items and hide their cheaper substitutes. This is most visible in their produce section - if you go in looking for grapes and without your senses about you, you'll pick up organic grapes by default. It also means that shopping at Safeway is mentally exhausting, since I've got to recalculate the 'best' prices on everything I buy every time I go there - so I avoid it now. <end rant>

How do we chat in the repl? I'm getting messages I'd like to engage with.

You should actually constrain volume to 1-100. I'm currently listening at 2000, and I tried 1000000 and it was painful.

It's false to think that automation must create jobs, although it's a tautology that it does destroy/reduce parts of them.

Your argument essentially amounts to "this is how it's worked in the past (unemployed people have been able to find other categories of jobs), so it'll always work that way".

Developers will benefit from some of the income, but won't get it all. This is because their initial benefit will draw more people into software development, which, if not coincided by an increase in demand for software engineers, will lower wages since it'll increase competition for jobs.

The poor will get poorer b/c they will have neither capital (money/development machines) and because eventually the rate of cannibalization of industries will increase over time. Software's eating the world, and that process is accelerating.

Machines alone won't be worth much more than the sum of their parts because they are mass produced and largely interchangeable, so there's a ton of competition in the market. They will still be under the control/ownership of capitalists because they won't be persons - everything that isn't a person technically has an owner.

When machines do cross the barrier of deserving rights, we should reconvene and have this discussion again.

I've seen a superior pattern employed elsewhere: a "grab code" hyperlink on the label of the promocode's text input that brings up a modal or opens a new tab that promises a 10% (or similar) discount in return for sharing on twitter/facebook etc. It can solve two problems - people looking for promocodes can find that tab instead of websites that show your promocodes while redirecting users to your website with their referral link, AND your website will get a bit of free publicity.

I'd argue that the biggest problem is not new technology and how it replaces workers - it's the increasing rate of change of technology, and increase in speed of new waves that replace / commoditize industries. In otherwords, I worry that we'll eventually get to a place where every month there's something dramatically better/more efficient coming out that will replace the jobs done by regular people. People take time to learn, and re-education for the jobs available will not be instant. That means that if the group of available jobs changes too quickly, we may find ourselves with a growing and unfillable skill gap, since nobody can learn the new skills fast enough to actually use those skills in production.

What are your thoughts? I'd like to pick apart this issue.

Things like fonts can be defined at a high level by higher-level css tags or classes. I usually use less instead of direct css, so for me I'd just throw in an import in each view's less file to get the default styling applied, or I'd just have basic font styling done at a higher level in css so at the level closer to the actual class, I'd only need to apply tweaks as needed.

I'm ignoring it because I'm assuming that you'll download the file ONCE from cdn.awesomesauce.com/oj.js when you're on my website, then the next time you return to my website, or you go to tom, dick or harry's website, once they have the same url for the file and it's cached in your browser, the load time will be near 0.

Currently, views are split into 3 places: html, css + js (for rendering updates - usually done with a template). The big difference here is saying that the view is actually all three things/ that it's made up of all three components, which is closer to the truth than other systems of thinking.

Can HTML be the view without css and without js binding for events and updates? Not in a modern app!

Can CSS be the view without HTML/JS? NO!

Can JS alone be the view? Yes, but you'd have a lot of inline css and html - it'd be and a pain in the ass to maintain.

So if you want a single, true View in your MVC, you'd need a view that has all three parts. Other frameworks like backbone try to do something similar - backbone allows you to let your view have a template, but backbone views rely on external css and often attach to dom elements that aren't even in the view's template. So what you have is a view that's only referring to/aware of a few of it's actual dependencies. That seems sloppy if you ask me.

Also, if I had a TweetView that was a backbone view, and I wanted to move it to another person's system - maybe I created an awesome design and called it AwesomeTweet - other people who wanted to consume AwesomeTweet without OJ today would have to include a css file, some html (or a template) and some JS. Each presents a rich opportunity for namespace collisions, and for my bad documentation to make it difficult to import AwesomeTweet as a module. Instead, OJ could allow a simple line like showAwesomeTweet('2131221121'), which would be guaranteed to work everywhere, simply.

Does this explain the "why" better?

Separation of concerns is increased with OJ: Your app doesn't just have one huge CSS file, but each view has it's own css, and it's own html(template) & js. This will significantly reduce complexity in larger apps.

Because SEO is so important, you should be really careful about the sort of assertion you're making - most people will read your post and assume that the googles can read html generated by js template rendering. AFAIK, this is false, and this is a huge problem for single page js apps - they're often SEO crippled.

Most people running js webapps are not following google's ajax webcrawling directives or paying seo4ajax to solve the problem for them. It's irresponsible to say that there's no SEO problem with client side rendering.

Sorry, but there will always be new tools and newer, better ways of doing things: best-practices will aways change, and people will always need to be re-educated. This is even more true in this industry than anywhere else, and I've noticed that the rate of this change has been dramatically increasing (which is why there's such framework fatigue in this thread).

Do you have any other reason why we shouldn't use OJ?