Readit NewsJust interested.
As far as "extending" goes though, it's not always clear. Is a date picker extending jquery's core? I personally think not, but there has evolved an expectation that every web component must be initialized like so:
$('#container').doSomething();
So I suppose a lot of people do it that way just to have a familiar look to their API, or even just to show up in listing as a jquery plugin.
I guess I am not everyone, so some people can find value where I might not. So, take everything I say with a grain of salt.
You have a point, but I've seen many non-polished, no pitch deck pitches that as rough as they were you walked away with a sense that they are on to something. They have some epiphany or insight and are attempting to turn it into something real. These videos (i didn't watch all) come off as people that have no idea what they are doing or even thinking other than, "I am going to make an app and be a founder."
The problem this guy has is that most serious entrepreneuers won't partake in his process, and this leaves over the large portion of people who don't have access to capital for a very good reason. Not to say there aren't many serious people who struggle with connections and who this guys offering is a good fit for, but his content strategy of sharing all these videos, even if a few have nuggets of gold is going to annoy viewers much like a listicle does after you click through to page 2 or 3 of a slide.
It's time to kill off this mantra of content, content content. We don't need more content, we need content that can't be found anywhere else. (admittedly, this guys content cant be found elsewhere, so that is a plus unless the content continues to be boring and lacking insights.
If you can hire a content writer to run a few searches and write a well written article...THAT IS NOT CONTENT WORTHY OF ROYALTY.
The only content that is king is content that you have to work hard to produce that cannot be found by reading half a dozen articles you found with 2-3 google searches.
I rather thought the videos were examples of what not to do, along with constructive criticism explaining why.
The idea on paper sounds like a clever way to piggy back for a relatively low risk level on a lot of startups...and as much as contrarian thinking is pontificated, you have to wonder if there is a reason things are done the way they are in the first place.
I am not saying you can't disrupt an industry, but you have to first understand why the industry does it the way they do in the first place. It's not like a bunch of dumb people got together and said lets do this thing as backwards as possible. I have never met an idea for disruption that didn't at some point come to realize that there are often forces beyond control at play and it is very rare to be able to actually disrupt an industry just because intellectually it seems backwards.
I think it's time to dial back the disruption rhetoric and focus on the value creation as defined by people willing to pay more than it costs to make, sign, seal, and delivered.
As far as the terms - I didn't look it over closely to see if it's a fair or predatory deal. Anybody know if it's a fair deal?
I am happy to be proved wrong of course, as it would be kind of awesome to have a set of trained bees doing one's bidding!
More likely the bees were "persuaded" to use cannabis by either proximity of the plants and/or treating the plants in some way to attract the bees.
At work I mainly work on two APIs that work closely together so in Eclipse I can have both open and just jump between the projects easily and at home I like to have all my scratch pad projects/ideas in one eclipse workspace so I can jump between them all easily.
I know there are kinda workarounds with modules but it doesn't really work well, if they allowed the ability for multiple projects in a workspace I'd jump ship but sadly it seems it'll never be supported (according to co-worker who is a die hard IDEA fan).
The first issue is that I've probably set up 10 or 15 app development and deployment "systems" if you will. I've found that it's very beneficial to automate the simple stuff but it quickly reaches a point of diminishing returns. A super-custom system always works great for a while until some big change or library upgrade or refactor or whatever comes down the pipe. Then we spend a ton of time resetting up everything. We have to keep the build system components up to date so it doesn't turn into an ancient mystery box. Sometimes an upgrade breaks the whole thing and then we're on stack exchange all day debugging a parser library or some other thing that we don't care about. Basically spending hours and days and weeks on the build system so we can have that sweet one-click (or fully automated) deploy.
The other thing is that we release frequently but we tend to double check everything before it goes to production. Our staging server is auto-deployed except DB changes which we do manually. Right now it's about 2-3 clicks for us to deploy to production and it works fine. We still do DB changes manually though. It takes a minute or two to deploy. I feel like the process encourages that final check that everything is cool.
I guess I'm nervous to set up something that deploys to production simply by adding a tag to a slack message or the git commit message. Should I get over myself? If I change my thinking is it possible that deployment to prod could be a non-event?
It's a clear sign of people with no clue about proper software engineering, which is glaring in today's front end world where dependencies and tools have gone amok to manage mere hundreds lines of CSS or Javascript.
Just provide a download link to the min file and be done with it.
I just started to use npm (and indeed package managers in general) for my work recently and it's opened my eyes. It makes sense to me that this will be the preferred way of working for every dev/designer. Just as we mostly all use git now. It's hard to imagine that time when we just shared files via FTP and didnt use version control. I'd encourage anybody like me who was resistant, or working on a large code base that doesn't use those tools - give it a fair try on a side project.