Glad to see Boeing catching up :) The headlines in this space have been dominated by big names who are yet to demonstrate real capabilities, so it's good to see them taking baby steps.
Case in point: Our startup has been quietly flying a similar technology demonstrator since early 2018. While we don't get nearly as many headlines, occasionally something comes out: https://www.wired.com/story/beta-ava-flying-car-aviation/
PS: We're hiring :) If you are into hard software problems and want to join what could be the next Tesla but for aerospace, send me your resume: artur@beta.team
Obviously this is a very personal matter - i.e. if you don't enjoy managing people and prefer to tinker with, learn, and build things, pursuing a management career is the worst choice you can make from a happiness standpoint.
It's also not generally true that managers (even those with fancy titles) are more financially successful than engineers. By definition, there are far fewer VP/Director level positions than there are engineer positions, so everything else equal, as an engineer you have a lot more opportunities to pick and choose where you want to work, and that can be very financially rewarding.
I personally joined Twitter over a year before its IPO, and the financial reward there transformed my family's life. I am also incredibly proud of the products I've built over the years, whereas most work done by Directors/VPs at smaller companies wouldn't even come close to the reach and visibility of the work me and my fellow colleagues have done. (Take a look at my resume for added color: http://linkedin.com/in/arturadib).
One could easily imagine an opposite article written by someone who was a VP at several not-so-successful companies and never had anything to show.
Above all, choose what makes you happy. And if you're so fortunate as to have several equally fulfilling choices, and if financial reward matters to you, pick a company that is high-growth, hopefully pre-IPO, and negotiate at least a market-average stock compensation (glassdoor.com is your friend here).
Above all, observe the #1 Rule of Business, similar to the #1 Rule of Dating: Always Be Successful. Then his choice would have worked out well no matter which path he would have taken.
Even being in California? Salaries I've seen have been not that great considering the cost of living. If I can get 6 figures in the southern states, why would I go out to Twitter/FB/Google etc?
I don't know if the parent will reply, but I've heard of twitter giving out million dollar stock grants to senior engineers _after_ the IPO. I can only imagine that pre-IPO stocks would have been even more.
Github has special rendering for Markdown and CSV files. Would be awesome if they did the same for Lilypond and/or MusicXML and made such files playable.
Definitely, we already provide a transparent "fork" feature for teachers. With that they can easily distribute copies of their own documents to all their students.
You might want to brush up on business speak, that's the real reason for writing the vast majority of all software ever written or that will be written in this century.
The point is that it is possible to be able to pitch a technology to management without being overly opaque and sounding like a bag of buzzwords.
Also, keep in mind that different industries are accustomed to different sets of terminology. Engineers at tech companies don't usually use terms such as "product delivery" and "Continuous Application Lifecycle Management." To us, "multi-cloud orchestrator" is a much clearer way to describe this technology.
It's odd, I am an engineer at a tech company that works on the Salesforce stack so I use the phrase "product delivery" all the time and "continuous application lifecycle management" is a perfectly normal phrase to me. It's really all about different industries, even within "tech".
Few know that Green Mountain Coffee (now Keurig Green Mountain) was started is still headquartered in Vermont. (GMC slowly acquired Keurig in the 90s, based in Massachusetts).
I have been living in VT for the last several years, and I'm pleasantly surprised by the sheer scale of unicorns this state has produced over the last 10 years: IDX (sold to GE Health for $1B+), Dealer.com (sold to Dealertrack for $1B+), and Keurig ($10B+).
Let this be an inspiration for entrepreneurs outside of Silicon Valley and other innovation hubs!
I've been using Meteor for months. It's such a pleasure to work with. It's what Rails should've been if it was written today.
They just keep on delivering on out-of-the-box functionality, compatibility with 3rd party libs, and more importantly - on a very solid architecture for real-time transport by guys who really know what they're doing.
Exact same experience. Development is easy and frustration-free. The team listens to the community AND delivers.
The platform is not just for playing around anymore, it has matured really well. See the case studies[1] - I, for example, love Hansoft X[2].
I think I would feel frustrated to have to go back to any other framework. Meteor is what web-development should be like. I'm not sure if Meteor is going to be THE platform everyone is going to use, but it definitely is completely changing the game and I suspect web-developers will be adopting the Meteor ethos.
I don't think either that Meteor is going to become de facto platform for all web development, but it's definitely going to be one of the main ones along with Angular, React and Rails.
I'm curious - do you think there is room for someone to come along with the right combination of stuff to become the "de facto platform for all web development"?
It's interesting also that people always talk about Rails but don't mention JSP and .NET, which I think are actually a lot more popular last time I looked around. I guess it depends on who you ask.
I feel like JavaScript is in a sweet spot right now because it has the inherent advantage of being the _only_ language you can run inside a browser, so you can do things with it that would be very hard or complicated in other languages.
I've wondered to myself a few times: perhaps Meteor would be even more popular than it presently is, if it had not been chained to MongoDB from the start. Even a different NoSQL db would probably have been a more popular/respected choice, at this point.
And, though I know this has been said before, it bears repeating: most developers who deal with data on a regular basis are best advised to go ahead and get comfortable with SQL. So far, it is BY FAR the best solution to the great majority of data-storage-and-retrieval use cases. I'm no expert, tis true, but I don't see JSON objects replacing SQL any time soon.
So, yes: as soon as Meteor includes official support for one of the SQL platforms, I'm all over it. It seems very promising, for those of us not locked in a death-rattle of foaming, red-faced JavaScript hatred.
Good question. I think Meteor is certainly the closest of such platform at the moment, but you don't have to go far to find a developer who really hates JavaScript and will never switch over. Such hate may or may not be justified, but you won't easily change their minds. At the same time, there are people - including me - who only develop with JS with no real need to switch over to something else.
I wish I had a more educated answer (guess?), since this is all just anecdata.
Has anyone built an Ecommerce platform in Meteor? Meteor is just this months hotness for building a specific type of web product, namely web apps. It's not going to become the defacto standard of anything else.
I've messed with it some, and so far, I'm not seeing what the advantage is on using Javascript on the server rather than Ruby or some other more advanced dynamic language. Ruby seems to have more advanced features and a better ecosystem around it.
I'm a data guy whose realized that all of the fancy data stuff in the world tends to be useless without a UI. I don't have time to put all of my effort into web apps, because then I'd have to take my focus off the data/business functions piece.
Meteor has been perfect for me. It works, I can easily integrate with it via the Mongo back-end, and the prototyping is super-fast. For the kinds of apps that I build (very industry specific apps for retail) I don't really have to worry about scaling to thousands of users, which means that Meteor isn't just a toy in my world. And even if I did have to scale, everything about the Meteor framework indicates that scaling Meteor is no different than scaling any other Node app.
When Postgres support comes, (its in the works) I'll be using this thing for everything.
Still waiting for the killer testimonial for meteor, until then I'd be too scared to try it with anything larger than a prototype or brochure site.
I don't want to be the first person attacking a completely new class of scaling problems using a proprietary tech stack that I may or may not have the ability to control.
Proprietary is the wrong word, as it is open source. The right word would be "immature", as meteor is an entire tech stack that hasn't been battle hardened by years or decades of other software that currently exists in other tech stacks.
The other piece is the meteor stack is designed to be hosted by meteor. Sure, you can, in theory, run everything yourself - but I haven't seen good case studies of that. What do you do when your app blows up and suddenly the hosting costs of meteor is too much of an overhead?
So... as it happens I have a lot of experience deploying Meteor apps to servers that don't belong to Meteor. In fact, I may have a greater variety of such experience than anyone.
As the lead developer of Sandstorm.io, I have deployed Meteor:
* As the Sandstorm front-end, where Sandstorm is designed to be installed by end users on their own machines.
* As apps that run on Sandstorm, and are designed to be extremely fine-grained (each app instance handling a tiny amount of data, e.g. a single document).
* As oasis.sandstorm.io, a highly-scalable centralized Sandstorm host.
* As apps.sandstorm.io, a fairly mundane use case (whereas Sandstorm is, comparatively, highly unusual).
I would argue that Meteor is not at all designed for Meteor hosting. Rather, Meteor is designed such that anyone wanting to build a PaaS around it will have a much easier time doing so than they will with just about any other environment. On Sandstorm, we find Meteor apps much easier to package than anything else, because the Meteor tools will output a self-contained app bundle that operates in a consistent fashion for all apps -- thus allowing us to write a common packaging tool that works with all Meteor apps. Other stacks are comparatively much more fiddly.
I would expect Meteor's hosting will turn out to be the best way to run Meteor apps primarily because they have kick-ass engineers there who will build an awesome product (disclosure: I know several of them), not because they've biased the framework in their favor.
> On Sandstorm, we find Meteor apps much easier to package than anything else, because the Meteor tools will output a self-contained app bundle that operates in a consistent fashion for all apps -- thus allowing us to write a common packaging tool that works with all Meteor apps.
What does that mean exactly? I admit, I only kind of know what sandstorm does from it's marketing page (looks like it offers VM's in a more user friendly way with an emphasis on security)
In what way does Meteor allow you to produce quicker or more efficiently than if you went with any standard linux stack?
Try installing Wekan, which is a Meteor-based app.
The thing that makes Meteor easier for us is, as I said, the meteor tools have a command "meteor build" which gathers all of the app's code and package dependencies and puts them into a self-contained directory tree with a start script that is executed the same way regardless of the app. This makes it easy for us to build a tool which turns any Meteor app into a Sandstorm package because the input is in a well-defined, self-contained format.
We are, of course, building tools for other stacks as well. It just takes more work.
You can easily use things like Heroku and Modulus to host your site. I think perhaps you are misinformed about your options and should read up a bit more.
I use Digital Ocean with MUP and it works great with minimal efforts.
What kind of load does that app you host on digital ocean have?
Edit: I'm not at all suggesting that isn't possible to self host a meteor app, I am saying that I don't know what the "beaten path" is for other companies/apps/products that have self hosted a meteor app to a significant scale.
I had totally different experience. I don't have much experience on meteor just working on some tasks for a meteor project. Hence issues might be related to it as well. But I felt it was very amateurish, there was no proper ordering/routing like in rails. I had to guess debug a lot to identify the source of files. Mongo was a pain to work it. My biggest issue was speed. It took a long time to reload after changes. From this experience I am not interested to work on meteor.
Works great. Just isn't part of core. Meteor core is stubbornly trying to force use of atmosphere for everything. But everyine I know immediately installs https://github.com/meteorhacks/npm which allows for using regular npm packages.
I think inevitably the meteor team will bring this into core, or something similar, and we will be able to have our mix of atmosphere and non libraries.
