There is potentially a big legal difference between tinkering on your side projects at work, compared to carving out time for them at home. Unless you have a specific exemption in your contract, then your employer owns all your work that you do in the office or on their equipment.
I'm a full-stack freelancer with experience managing, developing and deploying projects in PHP (Symfony, Drupal), Python (Django, Flask) and Javascript (Node.js, Express, AngularJS, React). My specialty is working with front-end build systems and automated deployment for single page apps.
I'm located in Victoria, BC, Canada, and am available for daily, weekly or project-based work.
How many data points do you need to uniquely represent every person in earth? I bet its a smaller number then the number of constraints and requirements in your system.
I'm sorry for coming across as a dick, but the idea that you "wasted" time learning a framework that became obsolete is silly to me, and it seems to be a common sentiment.
Ask yourself: at the time you used prototype.js, did it save time on the project?
If you answered Yes, then it was never a waste of time. Knowing prototype.js AND jQuery makes you a better developer: you learned the hard way that abusing prototypes can lead to hard-to-understand code. That can only be a good thing!
One hard lesson I learned is that you can't bet on a front end framework having the same mindshare for very long. The churn can get pretty crazy, and in my mind this nudges the needle a bit towards rolling your own for long term projects. Especially if you can offload the complex parts of the arch to the lower-churn backend world.
I agree there. Deciding on tooling for a long term project is a very tough balancing act.
Although I am a bit afraid that people overestimate the costs of rolling your own code, or "re-inventing the wheel". In most cases you aren't reinventing the wheel, because there are well documented bodies of reference for the design of almost any wheel you could need. Building (writing) a wheel (code) from scratch against a spec is much, much less complicated than inventing it.
Likewise: assembling your own set of design patterns and writing code from scratch is not "re-inventing", and is a lot easier than we give it credit for.
Those problems are best solved with Engineering best practices and culture, in my opinion. Each tough / innovative problem is probably somewhat unique for your startup, and picking a solution (a front-end framework) before you even know the problem limits your ability to solve it creativily.
Most programmers are good enough that with a good refactoring culture, they can evolve the equivalent of an in-house framework. Although, for some reason, I gather that programmers are scared of in-house "frameworks". I think that attitude is short-sighted since the app you build on top of the framework will end up being more complex than the framework itself.
What is wrong with leaving everyone high and dry? The CEO has no qualms about doing that to devs.
If an engineer leaving puts the company in a bad spot, then they are understaffed and need better management that can foresee and handle those transitions before they happen.
It's far worse on low-memory Android, in my opinion. iOS apps have to support being suspended and resumed (although bad apps still do it badly). This forces apps to deal with this eventuality on day 1.
Android, on the other hand, doesn't force this. All apps assume they can do whatever they want in the background, without being shut down. This means, on my low-memory Android, that opening an intense browsing session followed by Google Maps kills all of my background chat apps, making me unavailable. This is far more unacceptable in my opinion then having to wait for an app to reload.
(I would agree that iOS is too aggressive when it comes to memory management, though)
That almost looks like it was built by a mechanical engineer, not an electrical engineer. All the effort seems to be focused on building a sturdy case for the batteries, and the actual electrical connections are all steel screw terminals and crimping, without any spot welding anywhere.
I'd be worried about the electrical resistance of all those contacts, and the heat it produces. Tesla's battery pack seems like a more intelligent electrical design, with a barebones mechanical design to back it up.
I think your last paragraph is generic enough, we can use it as a reply to your comment:
You really aren't that good as you think. Your problem is you grossly overestimate your capabilities and achievements. We all were there, most of us outgrow it. You will too at some point.
What problems do dependency injection solve for you? I haven't had a chance to use it yet, and I've always been curious about its benefits in real projects.
I'm really excited to check out this Nunkucks project. I ended up evaluating a bunch of JS Jinja-style libraries and also ended up choosing SWIG.
Unfortunately, SWIG does not run well in the browser. The code is converted with Browserify, and the browser tests only cover the simplest use cases of the library. Thinks broke down horribly as soon as you used a tag ({% extends %}, {% include %}) that needs to load a template.
Is the browser a first-class citizen with Nunjucks? I'd like a library that supports 100% of the features (including compiling templates) in the browser.
Fortunately, with a bit of hacking, this style of syntax is possible without generators :) (I'm hoping to open source a library I wrote that works all the way back to IE6)
Here's your example rewritten in the 'monads' library (I probably need a better name):
monads(function() {
var ra = opA.defer();
var rb = opB.defer();
var result = opC(ra(), rb());
});