Providing an option to install with npm simply makes it more convenient for those devs who already use it - which surely is not an insignificant number. Nothing is requiring you to work that way or stopping you from downloading the files manually.
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.
I personally find it odd to create every component as a jquery plugin. To me, it makes more sense to write a plugin only when you're extending jquery core functionality itself in some way.
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.
Basically, this function is just an onMouseOver event, which then inspects the element and displays text from the "desc" tab in the right place.
I've been thinking for a while that it would be nice if we could add events to the CSS syntax, something like:
a[desc] {
onMouseOver: asideFunction();
}
I _kind_ of worry that this is subverting the purpose of the css, but since it also handles hover and selected behaviour, it seems like the line isn't well-drawn anyway as to where styling ends and where behaviour begins.
I think that most wars are are just based on the wealthy and powerful retaining or increasing their wealth and power. Average citizens generally don't have problems with each other. Excepting whatever propaganda we've been fed.
I found the videos really interesting to watch because we see lots of polished pitches here on HN, but here we're seeing everything. These are mostly just going to a VC with a hand out - asking for money. But, that's what pitching a company is. I think a lot of people who haven't done it imagine a slick deck presentation in a boardroom. The reality is that you have to be able to sit down in a coffee shop and sell your idea to someone who has more money than you.
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?
His terms are at your own discretion, but he assumes a few % points. (i.e you decide what to offer.)
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 agree about the quality of those few pitches I watched. But if you notice the red vs green monetary amount next to each video - all of them except one were rejected. So you can skip and watch only the green ones, I'd assume, to see the decent pitches.
I rather thought the videos were examples of what not to do, along with constructive criticism explaining why.
Same here. Not having multiple projects open is a total deal breaker for us. We have a couple of shared libs that go with our projects and not being able to have them all open together is painful.
I work around this by either checking the core libraries out into my new project folder, so ice got multiple copies around- and also I've got a core-Luba project that's literally all 12 core libraries we have that I can have open in one window with my other project open in another.
I can't seem to get into the game of fully automated deployments to production. It definitely interests me but a few things always hold me back.
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?
>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?
Sometimes adding some friction to the deploy process can be good IMHO. Continual deployment isn't good for every product or every team.
It can still get tested and smoke tested before deploying directly to production. If you cant trust your automated tests and smoke tests then you're setting yourself up to fail.
Very true, but what's the ROI for full automation?
If a typical 2-3 click deploy generously takes an hour, and they do 40 per year... then it would take 1 year to break even presuming that a fully-automated system could be built and deployed in 1 man-week. If the deploy takes 10 mins, can it be built in less than 1 day?
Ignoring the development time for a fully automated system, I think the real question is, "how does a rollback and unscheduled downtime impact the ROI due to unforeseen problems?" because it will happen, eventually.
I think it is OK to add tools to the process as long as the most critical parts are the least mysterious.
For instance, in a networked file system, the on/off switch for “move from version A to version B” ought to be about as simple as swapping a directory symbolic link. That way, everyone can see exactly what it is pointing to now, what it used to point to (as old version targets are probably in the same parent directory), and anyone can figure out how to roll it back instantly.
Given trivial on/off switches, the details of the rest of the system can start to gain complexity.
Also, it helps a lot to have something like a “beta flow” that is essentially a parallel replica of your production environment.
This is possibly the most interesting fumblebrag that I've read in a while. It has a few issues which have been hot on HN recently as well as some age-old problems.
The dependence on third-party services like maps, messaging, flight data, etc. is an interesting topic. Services that help you to get up and running in a couple of clicks are awesome at first. But they can become a burden when your usage goes up beyond a trivial amount. This is a great lesson about thinking ahead when choosing third-party providers - either by passing the expense along to your customers or having a roadmap to phase them out when you hit a certain volume.
Another point is the one-time pricing which, in my mind, is somewhat of a ponzi scheme for a business model. I always cringe a little when I see a cool new app with a "one time payment for life!" pricing. You just can't support customers forever with a single lifetime payment unless you are earning revenue in some other way (i.e. advertising). It's easy to think that you'll continue to gain more customers forever, but you're setting yourself up to be crushed by your own success. Unless you're planning on regularly releasing new apps and/or in-app purchases for your customers to purchase, it's not a long-term business model.
Sorry to see the Just Landed go - it looked like a cool app. I think there is a lot to learn from this post so thanks to the author for posting.
In theory, you can charge your average lifetime value upfront.
In practice, for a good app the lifetime benefit to users vastly exceeds what anyone would reasonably pay upfront. For example, I've paid hundreds of dollars to Dropbox over the years (and feel like I've gotten well over $1,000 of value)—but I would have totally balked at paying even $200 on signup.
That is true, and to make matters worse it's probably near impossible to figure the right amount out when you've just started the company. You don't always know how people will wind up using your app.
That's pretty much exactly what my perception is. Add to that, you're account gets shut down and/or frozen without warning and only a kafka-esque system to find out why you were shut down.
It makes sense that isn't true but I have to admit it is what comes to mind.
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.