skysight-inc/HackerNews huggingface dataset:
But passing in a function providing the time is a form of "dependency injection". It is a shitty name for the practice, but that's at least one way I saw the term "dependency injection" used.
The Myth of Universal Love
Rational Suckers
Good joke. You've already paid for it, remember?
I find it socially unacceptable to refer to the word "fuck" as "the f-bomb", it makes me cringe every time.
This isn't very difficult to configure in Sublime Text 2 for different languages.
Android does use the linux kernel and does have some of the GNU stack, but it's not directly comparable to Ubuntu.

I believe that we are going to be using our phones as our desktop computers in the not-too-distant future, and what Ubuntu is doing is one of the first steps to achieve this. Android has tried to do this in the past (Atrix), but the desktop experience was abysmal because the experiences were inconsistent.

I'm very excited to see how this develops, but Canonical is going to need some good endurance to see this to a point where it can compete commercially.
A criticism of DHH's post on Dependency Injection
If I remember correctly then it can also run Android apps in the same WM together with other apps. It actually shouldn't be too hard to replace Android's WindowManager with some other implementation (say, QT-based) due to the nature of Binder (Android's IPC mechanism).
I think part of the problem with JavaScript, php, perl, etc is that is there, by default, everywhere. A great many beginners do some very ugly things with it because it's already on the system they have and there's tons of not so good examples on the Internet to cut and paste. I'd bet there are plenty of people creating web sites who aren't entirely clear on where HTML stops and JavaScript starts.

Ruby, for example not only has to be installed on most older systems, you'd have to know that you wanted ruby in the first place. This alone acts as a giant filter. Anyone who knows they want to use ruby is already going to produce better code.

Edit: Please s/ruby//g with anything slightly more obscure than perl/php like python, go, object-pascal, etc. I'm not trying to be a ruby elitist here. It was just an example.
The judge dismissed the suit over a lack of standing, which the law specifically says he can't do. If the lawsuit was really so absurd, he should have had a stronger reason to dismiss it.
For a library that is GPL, you would need that library's authors to relicense it to allow it on the App Store.

It's not that reasonable: the Apple EULA requires things that directly conflict with the GPL, such as the EULA requiring non-distribution of the binary.
Access to Adobe Suite, iWork, Max/MSP/Jitter, and other software that I depend on for my work.
Wow, that was disappointing.

It says something about the fashion sense of a reporter if they approach the question this way. You should ask, "What capabilities are we going to want in our phone going forward?" and work from there, but fretting over brand awareness seems, well, a bit shallow.

Do you only buy a car because it has a "Hemi" V8 engine ? And wonder, "Do we really need another engine for cars?" Of course you don't. I would love a smart phone that was less susceptible to malware (the tension of programmability meets actual exploits against my bank account). If the current OS makers can do that, fine, if there is a new OS that does this better, that is ok too.
There is a whole field of psychology called positive psychology, and this is one of its practices. I don't know how well accepted it is in the entire psychological community, but I remember hearing about it in some undergrad classes. Here is an article discussing it some more:

http://www.health.harvard.edu/newsweek/positive-psychology-i...
I find switching cell phone towers to be something that happens sufficiently rarely that it doesn't matter if it skips for a second. I am willing to believe your mileage may vary. Really, if you are doing tons of work from cell phones, you may even prefer the mosh UDP protocol for its packet loss handling anyway: people should try it.

However, my experience has been that most of the people I have had go "omg, mosh sounds awesome!" are actually trying to use it from their laptop (not the phone) as they move from home to the office: mosh is not just overkill for that use case, it actually makes some "incorrect" tradeoffs. Maybe with an occasional "roaming on 3G" usage, but "from the coffee shop" not "in a train moving at 300km/h.

As for the mis-prediction issues, I guess we'll just have to differ on that one: if you like it, that's great, but the people I've talked to found the weird jerkiness that you get whenever you hit a prediction boundary awkward and jarring, especially as you end up with a boundary whenever you hit enter. I talked to the developer about the issue, and it didn't seem like something that could be worked around (semantically, I'm not even certain it is possible).

(They also may have fixed some of the more insane "visual artifacts" mosh was getting when I was using it: every time you'd hit enter in bash it would do this totally-wrong prediction of "take some characters and move them up a line, but not all of them". I thereby purposely didn't list it in my "downsides" list as the developer seemed to think that was fixable, unlike the mis-prediction boundary problem, but it certainly drove me crazy while using mosh.)
| By any non-mad definition, Sweden is not a
| banana republic

This can't be a kangaroo court! We're not in Australia, so there are no kangaroos here!</sarcasm>

The prefix "Banana Republic Justice" can also be seen as claiming that Sweden handed out banana republic-style justice in this case, not that Sweden is a banana republic.
It's probably more work to run an organisation with a flat structure, but it seems to be more successful if you get it right.

Define "more successful"? Valve has 250 employees, github 140. Are you saying that these are "more successful" than more traditionally managed/structured companies like Wal-Mart -- the world's largest retail company with $450 billion in revenue/year?
Open Source Data Mining/Pattern recognition on the Cloud
I'd be interested in talking with you - can you email me?
MB Air are too big and heavy these days. Go for a Samsung Series 9 or Chromebook, especially if you don't care about Retina. Certainly not the MBPro, they're incredibly heavy and overpriced.

I do basically what you're proposing here, with a lightweight ultrabook, and it works very well.
Well said

DI is not good. It's a workaround for lack of flexibility disguised as a 'good practice'
Is it actually limited to 8GB, or is that just what Lenovo says/is willing to support?

My x220 limited to 8GB in ever bit of published Lenovo literature, but I bought 16GB of RAM at the same spec as the 8GB I have running now and everything works fine.
Apollo is just fantastic. This is another video of Apollo demonstrating his skills:

http://www.youtube.com/watch?feature=player_detailpage&v...

I'm fascinated of how he "dances" around the victims and uses peoples own momentum.
Is he trying to say that everything we write today in Javascript will probably be rewritten like everything we wrote in Perl in the 90s got rewritten? That's probably true, but it doesn't mean "Javascript is the new Perl"

Perl had zero corporate investment from a application development perspective. Java had an enormous amount -- and still does. Now take a look at Javascript. Javascript is the first language since Java to have gotten this much investment across a lot of enterprises. Google, Microsoft, of course, but also the rise of startups like Meteor. For Javascript to go away the way Perl did for app development will require too much retooling.
See also: commandos vs infantry vs police

http://www.codinghorror.com/blog/2004/06/commandos-infantry-...
The author made this using MathBox, which was previously discussed here.

http://acko.net/blog/making-mathbox/
One reason is that mosh adds a bunch of latency itself that is at least comparable to (and frankly somewhat heavier than) screen (if you don't believe me, I can find a quote from the primary author), a latency which is itself somewhat noticeable: once you layer screen into mosh, the situation tends to get sufficiently unreasonable that even on perfect connections the jarring latency effect becomes worse (as when a mis-predict occurs you are now going through two layers: mosh and screen; of course for the prediction case, you are still just dealing with the one layer).

(Then, once you are using screen to solve problem #3, my argument is then that unless you need the features from mosh that deal with packet loss, you can start attempting to whittle away at any other things that may have been less-than-perfect regarding mosh, as you might simply not need it anymore.)

As for your contention that #1 and #2 are "anecdotes", it isn't like I'm just saying "engh, didn't work": I'm explaining exactly why these things are issues from first principals so you can evaluate whether they will effect you or not: it isn't like whether mosh requires weird UDP ports is somehow subjective.

I mean, let's say I had said "one downside of deploying a mobile application instead of a website is that if a user doesn't have a smartphone your content might be inaccessible to them"... is that an "anecdote"? Maybe all your customers have smartphones, and if so you can ignore that, but at least you are aware of it.

(BTW, if you want another example of where the prediction goes insane: if you mosh to a server and then SSH from that server to another server, the latency between mosh and the remote client can no longer be measured by the protocol, and the prediction system gets very confused and mostly ends up turning off. I had a long conversation with the mosh developer about this issue when it affected me. However, that's even rarer for people to run into.)
I agree with the tragic lack of tinkering, however, Samsung hasn't had to do anything radical on the design front to print crazy sums of profits successfully competing with Apple. They did of course have to produce great products.
It is one of those fuzzy, learn from experience type of concepts.

In my experience, taking shortcuts in tests breeds more and more shortcuts (as less experienced developers look to existing tests as reference). As the shortcuts accumulate, the tests become more brittle, less effective and harder to maintain. This is the path to having a test suite that you no longer trust.

Red -> Green -> Refactor -> Refactor tests
You can s/ dealers and franchisees with just about any other field containing pioneers and establishments, which suggests to me the reasoning might not be sound.

Specifically, it just seems that historically franchisees made a bet they had a competitive advantage, and bet wrong. So they codified their position into law instead. Given the expense and scumbaggery of franchise car dealers, I think a lot of people feel the industry could use a "grassfire".
This is one of my app ideas that I've implemented a few times over the last few years. I've even purchased two domains towards the effort. I love hearing that others are doing it as well.
While it can drive two external displays, it only has one Thunderbolt port. The only easy way to attach multiple monitors is chaining Apple's Thunderbolt Displays. Other setups may require Thunderbolt docks or the like.
State of the Python/PyPi dependency graph
"Dependency Injection" Considered Harmful: http://www.natpryce.com/articles/000783.html
Yeah, it definitely does. seems to come and go, but switching between apps or opening some feels pretty laggy at times.

Thanks, cageface, I'll try a reset.
Bootswatch is not going to help this guy, I imagine it'll only make the product worse - most of the stuff on Bootswatch is pretty hideous anyway.

Clearly, he has no understanding of design, and is trying to enter an extremely visual market. He needs to just hire somebody. No need to do everything yourself if those aren't your skills.
4.2.1 is the current version and the source was available on the day it released.
Regarding your example using default params - this is the same argument (http://weblog.therealadam.com/2013/01/03/design-for-test-vs-...) that DHH is addressing in this blog post.

Adam's post does raise an interesting point about the "mass" of the function. Since `publish!` now has parameters, the public API is more complex. Whether or not this trade-off is worth it or not will probably have to be evaluated on a case-by-case basis, methinks.
This is all fine and dandy (and obvious), but the point is that Google is not just a webmail provider. When someone switches to Gmail, it affects me, because it lets Google track and profile me that much better. Hence the original comment - "unplugging" from Google is basically impossible, because of the proliferation of Gmail use.
Toyota previews self driving car
Am I the only one who finds this post confused and unnecessarily mean? Roughly, the post goes like this:

1. DI is bad, mkay?
2. Ruby offers the best alternative to DI.
3. BTW, programmers *are* their languages.
4. Hence Ruby programmers are the best. QED.

What is odd is that #3 is offered almost as an aside, with nothing more than a link to the wikipedia article on "linguistic relativity" for support, and yet it poisons this post and turns it into a mean-spirited rant. It makes the entire post a personal attack on anyone who dares to disagree with it's assertion.

This is not okay! I happen to dislike DI even more than the OP, but to attack people on a personal level for liking it is just plain mean, and unnecessarily so.

When you assert the identification of self with technology preference, you reenforce a damaging idea that has no merit, which is indeed the very idea that ensures that such discussions often have more heat than light.

Shame on you, David, for using your position to promulgate an idea that is not only useless, but actively damaging to the community of programmers.
Integrating Linkedin OAuth with an existing django app
Regarding your last point, the undeserved areas aren't initially profitable. In the feared scenario, the franchisee spends money to develop that market, expecting to make a profit in the long run. The franchisee is taking a risk on this market. This law is meant to protect that risk and keep the dealer from jumping into the market after the franchisee spent their own money to develop it.
That doesn't sound elitist at all...
If your tests are not reliable and robust, you will stop trusting them.

This seems to be the paradox in much advocacy of strategies like TDD. We start with the premise that our code is likely to contain bugs. In order to detect those bugs, we write a lot of tests, perhaps doubling the size of our code base. Now, we can do whatever we like to the production half of our code base, as long as our tests in the other half all continue to pass when we run them, because magically that testing half of our code base is completely error-free.
The thing is, unit tests are another "use case" for a given piece of code. Many people here are saying, "I wouldn't do monkey patching in production, but it's not really a problem for stubbing in test code." And what happens when you want to make different use of that code in production? Sure, "YAGNI, rewrite as necessary" and so on, but ruthlessly applying YAGNI leads to code so inflexible that you need to rewrite a whole component to make a change in one class (or start playing with monkey patching in production code, but I have not seen anyone advocate doing that liberally).
tl;dr: guy talks about circumventing software in order to "get the job done". He does this on a blog whose styles where lifted from my own, distinctly not open source blog. So yeah, I guess that's a thing.
> Using DI is just a glorified way to have "globals".

How so?

> Wanna unit test? Pass in a modified function giving back the time you want.

Right. And all DI does is make it possible for the following constructor to be invoked without special knowledge or adverse coupling:

interface IArticleService {
void Publish();
}

class ArticleService : IArticleService {
protected IArticleRepository ArticleRepository;
protected ITimeService TimeService;

public ArticleService(IArticleRepository articleRepository, ITimeService timeService) {
ArticleRepository = articleRepository;
TimeService = timeService;
}

public void Publish(int id) {
ArticleRepository.Publish(id, TimeService.Now);
}
}
Perl wasn't universal across all browsers. I think JS was viewed as akin to Perl at one point, but when people came along and started writing it the right way, everyone had their "what? Javavscript?" moment. In a way, JS's path is the inverse of Perl's; Perl was an OK language that got a bad rep for being written in poorly. JS is a flawed language that got it's good rep from people finding clever ways around its flaws to write it the right way...I think that's what is missing here..although a well-thought-out article, to be sure.
I agree. It's a silly idea to believe that people like Gates and Jobs roles stayed the same after their companies grew beyond a certain point. When a company gets large enough, it's simply impossible for a single person to know or even understand everything that is going on. There are too many moving pieces and too many areas of expertise to cover.
the google-owned motorola has
> The terms of the licence make it possible....

No, they do not. In fact, the example you gave is exactly the example given by the FSF to explain why this does not occur.

http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForN...

It's not a conservative reading so much as an incorrect one, and it's also nothing to do with v3 versus v2. The concern about v3 is that it means that companies are not allowed to use patent or hardware restrictions to do an end-run around the GPL's user protections.

The "viral contamination" FUD has been around for over a decade at least; it's nothing to do with version 3.
Thieves break into Microsoft's office, only take their Apple stuff.
Dependency injection subjugates readability and simplicity of data flow for a narrowly defined notion of testability. Even in languages like Java, it's possible to substitute class definitions for mocked ones without having to thread a weird sort of test monad through code that otherwise serves a purpose.

I pretty fundamentally disagree with making production code more complex to make unit tests easier to write. Make the tests more complex instead and think about the natural units for testing. Maybe the natural unit for testing isn't exactly one class.

This is counter to the conclusion of the article: it's true one shouldn't force Java idioms on Ruby but also if the Java idiom doesn't translate well, maybe it's a bad programming idiom in general.
That would be a pretty cool way to play battleship :)
Google Admits it Delibrately Blocked Windows Phones from Google Maps
Very interesting read. I wonder if there are any concreate examples of this situation happening in the real world?
Testability isn't the only good thing about dependency injection. It's much easier to reason about OO code when objects only tend to interact with objects that they have been explicitly given. Too much willingness to introduce static dependencies increases the risk of creating classes with too many collaborators and/or responsibilities. This is a good example of how a testable design is often also a just plain good design.

Sure, the given examples of "Time.now" or "new Date" are innocuous and I agree that it's a good thing that Ruby allows us to write this type of code without creating a testability issue. But too many people abuse static dependencies for things like database connections which are:

1. well-suited to being represented as proper objects that are passed around

2. better off confined to a small area of the codebase

This is a complex issue and there's a delicate balance that needs to be struck. Otherwise you can end up with a codebase where a few classes are all up in everyone else's shit. That's when you find yourself in embarrassing situations such as some code not working without a database connection even though there's no real need for that beyond the tangled web of static dependencies chaining it to the database class.
Well said, very well said.

I really do like people who can both disagree and share their reasoning on that disagreement. They are priceless. Many, if not all, of my best conversations have started with "Chuck I think {that/you/we/this} is wrong and this is why ..." I've often felt that half a dozen smart people with this trait can go out and build anything you want. That is because they will cross check each other and in the end they will get more right than they get wrong.
They are not "already" going to produce better code. I have nothing against Ruby, but its devs are not endowed with better programming practices.

I do agree with you that it acts as a filter of sorts, but only for now. Anything that is not mainstream tends to act this way.
Vizio Refreshes It’s PC Lineup For 2013 – Adds A Windows 8 Tablet
This may be completely left field, but are you the same Peaker from #programmers on DALnet years ago?
Well Panic said they wouldn't be including mosh support into Prompt, their iOS app due to the license.

So there is that.
I got my daughter an iPhone 5, and although I prefer Android (ICS/JB, anyway; think I'd go with iOS over GB though), I do love the form factor. I've had more than a few near drops with the N4 while shifting position one-handed!
>One better solution in TFA's example is to pass a high-order function whose "functionality" is to provide the time.

Having a function or an interface as an argument is functionally equivalent. In fact, the interface is more expressive than the function as it describes more behavior than a simple function does. In both cases there is an "inversion of control" where the caller has to specify what object is passed in. So claiming that one is better than the other seems more personal preference than fact.
Create.js in 2013
I'm not sure I've ever seen screen add latency.

(And yes, I do regularly use mosh to deal with packet loss over a 3G/4G connection; that's its primary value for me.)

"Pervasive modern firewalls" is an anecdote. Even at cafes and such, mosh works, anecdotally, for me.
Get the retina MBP. You won't have to think about setting up, backing up, connecting to, updating, or securing a remote server if you do. Unless you enjoy doing those things, you are better off saving that time and especially effort for other things like family time.

I get awful headaches using anything more reflective than the MBA display, so unfortunately Apple's retina notebooks are all unusable for me. It is something to consider if you are coming from a high quality matte display like a Thinkpad.
Perl was never as popular as JavaScript has become lately,

I don't know what to say.

Spoiler: apparently ES6 is going to kill ES5. Personally I'm shocked.
> It's not enough to read method signatures. There are no explicit interfaces. Only implicit ones you devine by understanding the full breadth and scope of how parameter A is used in method B, all the way down the stack trace.

Unit tests are meant to explicitly define the code's interface, and Ruby makes it very easy to write tests. Unfortunately, in practice this doesn't always happen and what you're describing rings a painful bell.