drygh's comments

We also have higher level documentation, which is meant to serve as a sort of conceptual overview of the framework, as well as to show what the framework comes with out of the box. This section is written mostly in kramdown, which gets parsed by jekyll before it's turned into HTML.

The author seems to reach this by asserting that the things he currently values will not be possible when his health declines. How does he know that these values won't change by the time he's 70? The things we value constantly change. As kids, we value playing games, eating candy, making friends, etc. These values change as we become young adults, and seem to change throughout different stages of life.

The things the author seems to currently value can be found here:

> It (old age) robs us of our creativity and ability to contribute to work, society, the world. It transforms how people experience us, relate to us, and, most important, remember us.

Not all people value creativity, and ability to contribute to society equally though. The author seems to be defined by his work and ability to keep up the image as a highly-functional, productive, independent member of society. If this is how you define yourself, then of course old age looks like a loss.

> Americans seem to be obsessed with exercising, doing mental puzzles, consuming various juice and protein concoctions, sticking to strict diets, and popping vitamins and supplements, all in a valiant effort to cheat death and prolong life as long as possible.

People do this to live a higher quality life too, and the benefits are short-term. Ironically, not doing these things can arguably "rob us of our creativity and ability to contribute to work, society, the world", something the author seems to value more than anything else.

Here's a blog post that goes into more detail about the 300 ms delay problem: http://ionicframework.com/blog/hybrid-apps-and-the-curse-of-...

(1) Leveraging the growth of the web

History has proven that the web is becoming more mature and stable, and that it offers an excellent platform for development in most cases. The tools and frameworks being developed allow developers to build more efficiently. The web is a solid backbone that has only gotten stronger over time. Native mobile development has also grown in this aspect. However, how do we know the native pattern won't follow the same course as desktop applications? Sure, there will always be use cases for native mobile apps, just as there are critical desktop applications that haven't been replaced yet. The web seems to be more consistent, and as it continues to grow, it only continues to fuel the hybrid development community.

(2) Building off of a maturing mobile community.

For the most part, hybrid development is simply an abstraction over native APIs. If the native app development ecosystem slows down, becomes more mature, and stable - it helps the hybrid ecosystem. The fact that iOS and Android are becoming the standard helps reinforce this idea. This allows us to build those abstractions and tools that make hybrid development possible. Exponential growth and change are the enemies of hybrid.

New native platforms and functionalities are like earthquakes. The architects and engineers on the surface who rebuild are the hybrid ecosystem. Over time, the world introduces new tools for these architects and engineers to make them more productive. This is the web - the fuel for the hybrid world.

So what happens if the earthquakes become smaller and less frequent? What happens when the architects and engineers begin to become more effective, at the same time?

Anyway, other than the previous points, the author summarizes the decisions to be made by businesses quite nicely. It's all about measuring the trade-offs...

Anyway, Ansible has been great for small/medium sized projects. I haven't used it for anything large, so I can't really speak if you're planning on working on big projects. I was able to pick it up in a day, and after a few days I felt I was comfortable with it. For me, copying parts of other people's playbooks from Github and trying to understand it was the best way to learn after getting an overview from the documentation. Just start with something small - like installing & configuring a database, and work your way up the stack. Can't speak to any other dev-ops tools since Ansible is the first I've learned, but I've been happy with it.

I do think having unique context could be pretty interesting. The narrower and more specific a list, the more value it would add. Having a "My Top 5 Books" list provides no value to me. A recommender algorithm will win at that game. However, having a "Romantic Thrillers Where Protagonist Gets Kidnapped While On Vacation" list is at least something unique. I think search could be kind of addictive if there were tons of random and extremely narrow lists. If you did go this route it seems collaborating to build the lists would be pretty cool. Having lists tied to a user seems like it would make it harder to come up with really unique and narrow lists as a community. Maybe you could have both?

Overall though, it was the negatives on the social side of things, rather than the physical, that caused me to stop.

That's why I brought up the contract as well. Not sure if this is a good cautionary step to take, or if I should do it in addition to putting APIs into 'test/sandbox mode'.

My suggestion is to pick a category - whether it is games, web development, mobile, etc - and start a project there. As others have said, dive in over your head. Take it one step at a time, it will be slow at first. No matter what you are doing, utilize search engines and Stack Overflow. They are your best friends. Don't worry if you use a framework and feel completely overwhelmed at first - it's normal. Also, learn Linux. It will make your life easier, and give you a better understanding of how operating systems work.

Lastly – just some general advice about something I have learned. You will hit some rough patches where you spends hours or even days on something trivial. This is part of the learning process. Becoming a better programmer means you organize your projects differently, and you learn how to debug more efficiently. Something cool about this though – sometimes you have an error and try 10 different fixes. None of them work. This is not wasted time – you just learned 10 new things, and chances are next time you will be able to debug a little bit more quickly.