827 karma · joined April 30, 2012
That being said, I absolutely think we will see EV planes in short haul -- and short haul flights are a HUGE source of emissions. This is good.
Here's a link -- local seaplane company is moving it's fleet to EV planes and has been flying test flights for almost a year: https://www.harbourair.com/harbour-air-magnix-and-h55-partne...
> Did you know that the first Matrix was designed to be a perfect human world? Where none suffered, where everyone would be happy. It was a disaster. No one would accept the program. Entire crops were lost. Some believed we lacked the programming language to describe your perfect world. But I believe that, as a species, human beings define their reality through suffering and misery. The perfect world was a dream that your primitive cerebrum kept trying to wake up from. Which is why the Matrix was redesigned to this: the peak of your civilization.
When VisiCalc was released departments of 30 accountants were reduced to 5 accountants because of the improvement for individual worker efficiency, however accounting itself remains largely unchanged and accountants are still a respected profession who perform important functions. There's plenty of programming problems in the world that simply aren't being solved because we haven't figured out how to reduce the burden of producing the software; code generation will simply increase the output of an individual software developer.
The same forces behind "no-code" are at work here. In fact I see a future where these two solutions intermingle: where "no-code" becomes synonymous with prompt-driven development. As we all know, however, these solutions will only take you so far -- and essentially only allow you to express problems in domains that are already well-solved. We're just expressing a higher level of program abstraction; programs that generate programs. This is a good thing and it is not a threat to the existence of our industry. Even in Star Trek they still have engineers who fix their computers...
This worked very well and I was able to tweak the PEG pretty easily. This article was a great read and reminded me that PEG is great. I'd love to do that again, it was fun and I could really use another PEG.
Nowadays, I accept this reality is largely impossible and you must always draw some boundary. This doesn't mean all your developers should use a shared MySQL because nobody knows how to bootstrap the database- but it means you have to consciously decide where you sit on the continuum. Always expecting to run the whole system on your laptop (or even in a cloud) is also an unreasonable expectation, unless you're Netflix and your revenue per employee is into the millions. The reasons for this are many and complicated, but at a high level the work required to make it happen will cost too much and won't be a priority.
I'll quote here from the excellent "Testing Microservices the Sane Way" by Cindy Sridharan:
> asking to boot a cloud on a dev machine is equivalent to becoming multi-substrate, supporting more than one cloud provider, but one of them is the worst you’ve ever seen (a single laptop)
https://copyconstruct.medium.com/testing-microservices-the-s... "Full stack in a box- a cautionary tale"
I agree that war should be avoided and "the only way to win is not to play"!
However, I think we should also be considering globally how we can act more like Holons [1] for greater resilience from all types of threats to global interdependence. We want loosely coupled systems, we should want loosely coupled government too!
Perhaps, rather than a studio, this is why we see incubators like YC; helping a ton of startups grow and finding funding for the best ideas.
Maybe we will see a movement further down the chain: finding entrepreneurs or "proto-founders" - founders before they become founders - and coaching them on idea generation and developing their passions. I suppose an example of this was Thiel's scholarships and the various "founder schools" that we see.
Innovation is hard to teach, but it's not impossible. Perhaps these trends will continue, and I wonder what we will call the organization format that this leads to.
edit: formatting
> In the past year I think I have finally come to understand the ideals of Unix: file descriptors and processes orchestrated with C. It's a beautiful idea.
We just keep moving up the stack, it seems :)
Source: https://gist.github.com/cookrn/4015437
(edit: formatting)
It would be tricky to do it well and proper, but perhaps they could introduce monetary rewards for question. Take a cut of transactions, pass on cash to recipients. Could obfuscate the % of the cut by using tokens or similar.
I've definitely received answers so good I'd have paid for them! I've also had questions that were difficult enough to warrant attaching a real monetary bounty.
Perhaps another angle would be something like CodeMentor. A system where you could pay someone to mentor you, but buying from a user profile backed by the credibility of answering questions on the subject at hand.
Social Media Management software used by 80% of fortune 1000 companies.
We need Senior Developers who are passionate about DevOps to come solve cool operational problems with Terraform, Ansible, Python, Go and whatever else gets the job done. From gritty networking to MongoDB load testing to automating all the things, all from Hootsuite's fun offices in beautiful Vancouver.
Profitable. Cash Positive. Growing Like Crazy.
Process: culture screen - tech screen - tech interviews - offer.
As you say though, put it in memory first and write it out to a DB every now and then.
I work at a place that has been trying to undo the damage of having serialized BLOBs for about 3 years. Granted, these are especially nasty things with a custom serialization layer written in Java.
Software companies consist of two assets produced by it's employees: data and algorithms to make the data useful.
Why would you ever lock your data down and make it harder to make cool algorithms to make the data useful?