skysight-inc/HackerNews huggingface dataset:
For some reason that I don’t completely get, a little gray hair and a smattering of experience in different technologies can create a beneficial bias for companies when they are renting brains instead of buying them outright. It may have something to do with the tendency for consultants to be vetted from higher up in the management chain where the silver foxes live.

I can explain this. It's a very old idea. The truth about the young hires is that they're cheap and the work they do isn't very important, but they're hired based on the potential to rise a level or few.

From an executive perspective, you don't hire juniors for the work they'll do, because it's usually not of high impact of value. You hire based on the probability that they'll be high-impact employees later. It's impossible to predict this at the individual level, so you're building a portfolio.

Of course, in 2015, the one-company-for-life model is pretty much dead and most people who get executive positions get them by job hopping at the first sign of an obstacle. Likewise, companies invest very little in their junior employees and tend to hire top-level talent from outside. So the biases from the old days don't really make sense.

If someone's 40 and still a junior or mid-level engineer, the assumption is that he's "too old" to become a high-impact employee in 5 years. It's completely ridiculous, these days. He could have been doing something else, like trying to make it as a novelist or working in a dive shop. It's a hold-over from the employment-for-life, gold-watch era.

For the consultant, he's not selling himself on some hazy "future potential" factor, so no one cares how old he is or (more relevantly) how old he'll be in 10 years.

Very few people actually think that young, junior programmers are more skilled or better at their jobs than the 50+ badasses. The issue is that the young juniors come with a 5% chance of being a high-impact, executive-level employee in 10 years. Since the people making big decisions are executives who tend to discount the importance of everyone but executives, this still matters... even though the one-company-for-life model is pretty much dead.
go to the datasources tab and see if there's an error message from data source creation. i had the same error due to an issue with variable names.
I agree.

I like take an onioned approach to software quality:

* unit tests
* release consistency (build artifacts and
dependencies tracked as an atomic, reproducible unit)
* some type of deployment/startup sanity tests
* development environment integration tests
* staging environment integration tests
* statistical anomaly detection on one production box
* application and infrastructure metric monitoring

This is not a prescriptive list; just something I've found works well for continually deployed systems.
"If you know you will never change the implementation or configuration of some dependency, there is no benefit in using dependency injection.".

It all boils down to this.

Here's the catch, though: with dependencies, it is really, really hard to know whether dependency implementations change or not. What is more, in most languages, implementing dependency injection is so trivial that it is always worth it. Conversely, the work associated with changing implementations that aren't built with some form of loose coupling, that is, designing around DI, is in most cases non-trivial.
But it does go on US2 in Montana, which is one of my criteria for an "optimal" trip through US.

But insofar as Nebraska is concerned, I have relatives there, and during one family reunion, we all went to the 4th of July parade in Hoskins. The large painted sign said "Parade at 8 am, pancake breakfast at 8:30". Not a large town.

But then I grew up 6 miles outside of a town of 3000, so I am not all that in favor of large towns.
> Those statements imply that if you are not using Dependency Injection (DI) then you are not doing OO "properly", that you are an idiot. I take great exception to that arrogant, condescending attitude.

Stuff like this makes me question if this guy has some deeper issues he needs to work out before he can write blog posts about design patterns. The entire thing reeks of clickbait and narcissism.
Do you mean like the offices that they have, or the datacenters that they run?

In both cases, the answer is yes.
This is really neat. Thanks for sharing! I'll pass the learn.tedpak.com page to med students I know.
It's tangential because it in no way excuses the student from unauthorized access.

It doesn't mean the school didn't have poor password policies. It just means that this is a wholly other debate.
Maybe find alums to run a mock interview?
I used to use Gitx but source tree is considerably better.
And plenty of comments here parrot exactly that same nonsense. What he might have done is totally un-important, what he did is what matters.
The Gelman-Nolan paper is from 2002; the Diaconis et al. paper is from 2007, and cites Gelman-Nolan. Gelman and Nolan are pretty smart, but they don't have a time machine.
I've sometimes toyed with the idea that users of SQL would benefit from having a block-like representation of the language: there are big multi-clause statements (particularly "SELECT ...", with lots of different places where values need to be plugged in, and a classic source of difficulty for novice/intermediate users is to know what kind of values can be used where, e.g. if you produce a value in the SELECT clause, you can't refer to it by name in a WHERE clause, but you can refer to it by name in ORDER BY. Another is that there's a less than obvious relationship between the GROUP BY clause and the SELECT clause.

A well-designed block language could offer a lot of guidance on these sort of points, perhaps by having a context-dependent pool of available blocks to drag into the body of the query.

At least, doing that would make more sense to me than any graphical query builder I've ever seen, with the bonus that it might lead to users who are more capable of writing SQL directly. (Not that I'm holding up SQL as a paragon of language design - but it is ubiquitous, and very useful in a wide range of situations.)
Well at least he didn't title it "Dependency Injection Considered Harmful".
Block languages free the students by the burdens of syntax

Is nothing sacred anymore?
Are You Mentally Tough Enough to Be an Entrepreneur?
Dependency Injection, Inversion of Control and the Dependency Inversion Principle
Linux kernel initialization, part 5
It's not a thought terminating cliche at all, it is very sound business advice and you will ignore it at your peril.

Not all that long ago I did tech dd on a company that had exactly one very large company as their main unwilling partner. They claimed that they were 'too big to fail', guess how that ended?
The article is overly dramatic about DI. Parts of it sound like a mere "get off my lawn!" rant against OOP in general (godwinning just few paragraphs in).

There's praise for the Singleton antipattern, variables with an "obj" prefix as if objects were an odd thing to watch out for. There's an example of polymorphism achieved by setting a global variable before including a script. PHP (v4!) written like that would be icky even in 2011.

There is some good advice in there too, but overall design it advocates for seems to reduce OOP to mere namespacing of global variables and functions. I'm assuming the author doesn't use unit tests either (given that TDD is "poppycock!"). It's not surprising that DI doesn't fit that way of building programs, but I don't think that makes DI evil. It's just a tool for a different job.
Startup Adoption Agency: a place to adopt a startup looking for a new home
I think this needs more detail as to what stage in the tech lifecycle the businesses are in.

Obviously, I'm going to trust an electricity company to provide my business with electricity. I'm even going to trust laptop manufacturers to continue to provide laptops I can code on.

In both those cases, the thing I'm depending on is a commodity, where there is also either strong competition or regulation. There isn't much risk in depending on them.

The stage to be wary of is when a whole industry is still at product stage and people are trying to move them into being platforms, or using them to Innovate/Leverage/Commoditise (ILC, see Simon Wardley) to play ecosystem games.

i.e. Where the business models and how the industry will be vertically and horizontally sliced are not yet settled.

Those are the ones you should be wary of dependence on.
> He said that before this, the pair had been discussing a renewal of the deal.

This should be a case study for anybody looking to get into a BD role.

A partnership is fundamentally coming from a position of weakness, and the relationship is a way for both partners to partially fill in whatever gap they believe they have in their strategy.

Sometimes partnerships go south, especially when the relationship is highly asymmetric.

In this case Twitter was the stronger of the two partners and they decided not to renew. That sucks, but that's life. Don't build your entire business around a single partnership, because that signals to your partner that all they have to do to get rid of you is replicate what you do and cut you off. Once you've gone through the blood sweat and tears to prove the market, you've just given your larger partner free market development.

DataSift's website lists a number of data sources [1], but Twitter comes up first. More importantly, I suspect these sources are slightly massaged to look like they have more sources coming in than are really useful for their business model. e.g. is Wikipedia really in the same space as Twitter? They also have a bunch of minor sources but they're listed like they all rank equally. This is fine, most businesses would do the same to make themselves look better -- it's just advertising.

Another part of business partnerships is that you have to expose your weakness to your partner. Twitter is going to know at some point that DataSift's business model is heavily built around their firehose. They might even have some sense about what volume of business all the rest of those sources makes up to DataSift's business. Twitter also, through their other partnerships, has a better sense of the size of the Twitter Analytics market. Even if DataSift's piece is 15% of the overall market, Twitter has other partners it can use to get a feel for the other 85%.

Partnerships are dangerous. Know what you're getting into before you get into them, and try to only do them with similar-sized partners or you'll find yourself getting screwed over/screwing somebody else over.

1 - http://www.datasift.com/platform/datasources/
MySQL JSON Support announced
Why is it implicit?

Because if we have module A depending on module B via some clearly defined interface, but in fact the behaviour of module B also depends on global module C that is set up elsewhere, then B's interface no longer fully describes what A can expect.

If C's scope were limited to what's happening within B anyway then this would just be an implementation detail. If C were given to B as some form of explicit dependency by A, then it would be a specified part of the interface. However, if C effectively has global scope by any mechanism then there is now an implicit interface to change B's behaviour that A doesn't know about. Developers reading or maintaining the code for A, C, and anywhere else that can affect C if it's mutable, then need to be aware of what each other are doing, and changes to any of these parts of the code potentially affect any of the others.

(I'm not going to address your other point, because I didn't say anything about service locators in the first place.)
Pick Your Features
Greece DID default on privately held loans.

http://en.wikipedia.org/wiki/Private_sector_involvement
The problem is that there is nothing preventing the "ecosystem host" from deciding that a niche an "ecosystem player" is exploring is lucrative and worth pursuing.

You can fly under the radar for a while but if Twitter/Facebook/Google/etc decide your area is lucrative, they will go after it, whether that will kill one of their "ecosystem players" or not.

There is no partnership involved, they provide a service as a huge "blob" that is making them money and they don't care about 1 out of 1 million of their regular users. Your small company cannot call itself a partner, you've as much leverage as any user when it comes down to deciding to sacrifice you in the name of something else more lucrative.

I'd say explore the benefits to bootstrap but have a strategy to depend less and less on them or your time will come. And if you really want to tie your business survival to one of these ecosystems, get yours and theirs responsibility down in writing (and even that won't help much because a breach of contract for them will mean nothing in terms of dollars, while for you it'll be your existence).
Scalable AMQP RabbitMQ Node.js client based on callbacks and promises
> More options: - Go solo.

As someone who has been 'solo' for a very long time, I have to heavily disagree with this opinion. Going solo isn't as simple or easy as what the OP seems to be implying. Going solo means you are essentially working two jobs at once as it takes a tremendous amount of work and dedication to network, find good projects and keep them rolling in to pay your bills. To further exacerbate things, each year the amount of competition that you face ramps up drastically as more and more workers enter the consulting world who are unable to price themselves correctly and are willing to work for less and less.

Furthermore, by going solo, you are now assuming 100% of the risk as to whether or not your new consulting business sinks or swims. Chances are, just like any start up, you will sink. Additionally, you will have added burdens such as insurance requirements, self-employment taxes, various state/county-level taxes (such as gross receipts taxes) and a laundry list of day-to-day operations that you will need to perform that aren't related to software development.

Going solo really isn't for most people and I wish we'd all stop perpetuating this myth that it is somehow easily attainable. Remember, a solo consulting business is the easiest business you can start, maintaining one is the most difficult business you can run.
If you're looking for a simple, lightweight alternative to bootstrap, check out PureCSS by Yahoo:

http://purecss.io/
Yeah, kind of nonsense. He's part of the Labour party here, definitely not right wing.

It's true that Labour in Europe made a big swing towards right. It's now more often firmly at the centre, instead of left of centre, on a host of economic issues. And so you could then say he's rightish, especially in his European position as opposed to his Party position in the Netherlands... but then you can throw a lot of terms out of the window and it becomes impossible to label anything anymore.

For example, in Europe we tend to consider most Democrats to be Rightish-Wing, and consider most Republicans just 'way out there', the notion that democrats are leftist is kind of ridiculous here. Left would be the Green Party for example. But we call them left because in the spectrum of dem/reps in the US, they're relatively left. We could say they're both 'right' and then come up with other differentiating words to describe em, but it never really catches on...

Same with Labour on a national level, Dijsselbloem is part of labour and labour is generally left in the political spectrum of a country, for what it's worth.
I sometimes find LaTeX too verbose. And sometimes it's very tricky to do seemingly trivial things.

For web development, HTML, CSS, Javascript can be written directly, or generated by some other template language like haml, slim, coffeescript, sass, stylus, etc.

I believe the same applies to TeX. Although AFAIK there aren't template languages targeting TeX, treating TeX as "dynamic HTML" or just use your favorite language to generate TeX sometimes turns out to be much cleaner and more maintainable code. The generated TeX is not human-read friendly, but just works.
Avoiding road blocks in software projects
> I do not believe in the idea that it automatically provides benefits in all circumstances

Where 'it' is dependency injection, or, hey, anything else.

How about we have an interesting conversation instead of rethrashing a stupid one (here is my straw man: 'you use DI for everything without thinking.' Watch as a bash it...)?

Why do dynamic languages like python, ruby and javascript typically not use dependency injection?

You could argue that some of them (python) don't have a great unit testing background, but modern projects like node do, and you still don't see the DI pattern thrown around a lot.

In fact, you tend to only see it in languages that implement a native interface-based polymorphism, like java, c++ and c#. Even folks using go (http://openmymind.net/Dependency-Injection-In-Go/). Maybe rust too, but since the single ownership makes singletons an anti-pattern in rust, maybe not (at least I haven't seen it).

Could it be you can get by just fine for all your testing needs without DI?
I'm sure Datasift saw it coming.

I researched this last summer. Even before I was explicitly told all the original firehose contracts were five years long, I could infer it from attitudes and behaviours.

I'm excited that Datasift are launching interesting new Facebook features. They're a great company, with good technology.

I hope Twitter's "no data resale" attitude leads to them becoming irrelevant, as it is so destructive of much innovation.
Anyone doing business with Twitter is a fool. There are few companies that show as much disdain to their partners as Twitter does. With partners like these, who needs enemies?
Parent comment is talking about the entire ecosystem - not the specific markets.

As new markets emerge, it's less competitive (in those markets) and then prices drop (which drop the avg).

In general, CPC doesn't mean much if you talk in total aggregate (you need to look at the specific markets) and CPC still doesn't address volume (which is the other half of the equation).

I'm guessing most of the people decrying the search ads are doing so from anecdotal evidence rather than statistics.
It is if it's 90% of their business by revenue.

I've worked for small companies in the past that had dozens of partners, but most partnerships don't really do anything except give you brand logo to mutually share on each other's web pages.

It's like anything else, partners provide revenue to you following a power-law distribution, with a long-tail that provides nothing and a very select few that make up the lion's share.
New to game development, releasing one game a month this year
Sure it does (at least, as much as any other "intellectual" field, like accounting or law). Do you want the guy who knows X (or 3 variants of X, each sequentially in fashion)? Or the guy who knows X, Y and Z?

The key is, no matter the age, to keep expanding your knowledge base.
It becomes a lot harder to switch programming languages and tools once you are dependent on some of these IDE features. Switching from using Eclipse for Java to using Closure without quite the tooling you've had before could be pretty hard if you join a new team.
Maybe the fact that skill at using each package outweighs the differences is a conclusion on itself.
Twitter is quickly approaching the point where it has lost my goodwill and I will actively look for something to replace it. (Apple has already passed that point)

I understand the way big ecosystems and walled gardens work. I also understand that every large technology company that has come down the pike in the last 30 years has wanted to conquer the known universe. That does not mean I have to actively assist them in this activity.
Yeah, I'm sure it was significant source of talk within the company for a while. But what can you do? It's not like there are other Twitters out there. The value of Twitter is that there's only one. It looks and sounds like they're trying to diversify out to other sources, but none-of-them are Twitter and for whatever reason Tweets are like crack to market research firms.
After doing that enough times, won't it basically look like a smaller version of inline css?
While true, in 1996 almost everybody knew C or C++. Now, you can get a CSc degree without learning a manual memory management language. While C and C++ are a shrinking segment of the entire market, the market is growing.
I believe the biggest problem with introductory programming courses is that students are taught two things at once; programming logic and syntax.

To a newbie, rules like ending statements in a semi-colon, wrapping strings in quotes and remembering the casing of a function name can be difficult. Ask them to produce a program with branching and looping with proper syntax and things get needlessly difficult.

I tried teaching a programming class with pseudo code and I found the class seem easier for most than those that had to learn the same material in an actual programming language.

If you could relieve the burden of syntax initially, that's great. But they'll have to learn to carry that burden eventually like the rest of us if they ever want to produce anything of value.
I wish we could replace the posted article with your comment. I'm all for articles that challenge the way things are done and that cause us to reflect on why we are doing the things we are doing to make sure we're not cargo-culting - but this article is pretty bad for more reasons than I care to list. Your comment is great, though, and hopefully will find its way to the top of the thread.

People often get caught up in "the one true way to do things" mentality. This is engineering, they think, so there must be a single, indisputable, scientifically provable, ISO standardizable correct way to write software. Once I know the one true way, I can mechanically apply it and not have to think about it anymore.

Someone who subscribes to that mentality might go about creating a lot of ThingDoers with doTheThing() methods. In the name of never creating dependencies to concrete classes and having 100% test coverage, it is possible to lose perspective of what is important. If you've made your system less understandable and maintainable than a monolithic procedural class, you've missed the point.

Related functionality needs to remain grouped together for understandability. Abstraction seams need to be created in ways and in places where it makes sense, not mindlessly to every single method in a system. This is more of an art than a science.

One thing that I always keep in the back of my mind is FizzBuzzEnterpriseEdition. It's an absurd example of thoughtless one-true-way architecture taken to its extreme, making an extremely simple task incomprehensible but "pure." If I'm ever writing code and FizzBuzzEnterpriseEdition pops into my head, I stop and evaluate what I'm doing.

The fact is that in this field there is no autopilot and constant reflection and adaptation is required. What works in one scenario doesn't always work in another. What works with one codebase doesn't necessarily work in another. What works with one team doesn't necessarily work with another. Even if it worked phenomenally well in one situation, with one codebase, or with one team. This applies not only to design patterns but pretty much all aspects of this business.
In my experience, syntax error is a huge barrier to entry to programming. Block removes syntax error by making syntactically erroneous program impossible by construction, so it is of great help.