skysight-inc/HackerNews huggingface dataset:
Huawei and Cisco/Netgear (which was recently discovered to intentionally hide a backdoor [1]) hardware should be considered malicious and dangerous, and therefore we need to:

#1 - not rely on a few big players in networking equipment anymore, and instead focusing on helping smaller ones grow, preferably from Europe (not UK, though)

#2 - we need to pressure them and demand from them to have open source firmware on their equipment. Not open source? Not going to have my business then. This should be an unshakable principle going forward, especially from large government institutions, but also from end-users.

[1] - http://arstechnica.com/security/2014/04/easter-egg-dsl-route...
This might not be completely it.

Human physiology is weird.

Only in recent history have we married for love and in some cultures you don't marry for love. Previously marriage was more like a business arrangement between families. They were also more final because of things like coverture men generally owned all the property of his wife. The woman tended to lose their own identity and become an extension of their husband's identity. My grandma exclusively refereed to herself as "Mrs. HusandFirstName HusbandLastName." For example "Mrs. John Smith." She was never her own name after marriage. My mom said at the DMV they would specifically say on forms "women use own first name."

This sounds crazy but humans have the ability to manufacture happiness.

Since the partners in the relationships of yesteryear didn't have much of a choice in the matter they subconsciously were happier because they didn't have an easy way out nor did they make the choice. They couldn't decide otherwise so their brains manufactured happiness with the situation they were in. This isn't really "fake" happiness, it is real, there is nothing different about it. It is how the human brain works. There is nothing bad about this. It is kinda like a psychological immune system.

If divorce is easy and socially acceptable and you choose your partner from millions of potential partners your subconscious thinks "maybe someone else can make me happier" and you are less happy with your choice.

Our brains "make" happiness with the life we have if we can't choose an alternative.

Daniel Gilbert has a great book on this aspect of humans ability to alter their own happiness - "Stumbling on Happiness"

Here is his TED talk on the matter which has a lot of the same material as the book - http://www.ted.com/talks/dan_gilbert_asks_why_are_we_happy

The following is from my memory and might not be 100%:

For example - he cites a study in which students in a photo class were asked to choose and submit one of the photos to get blown up and framed. One group of students were told that the photo they choose was final and they couldn't change it and the other group was told they had two weeks time to change their minds and submit another one. When the students received their final photos the group who couldn't change their photo were more happy with the photo they choose than the students who had the two week option of changing their photo.

Another one is asking people to rank several Monet paintings on how much they like them. Then they got one to take home. When the researchers came back and asked them to rank the paintings again they ranked the one they owned higher. They like the painting more because they owned it.
This of course has nothing to do with staticness, and everything to do with Java's lack of first-class functions. In any flavor of ML, for example, nonzero-argument versions of this pattern are slightly cleaner (the exact pattern is unnecessary due to immutable state).

> or a macro that expands to inline assembly to convert a float to an int32_t

This sort of thing is actually useful on occasion, because it allows you to specify the exception handling you actually want (what to do on inf/-inf/NaN). Of course, it's better do it with a pure C function, but it's still a "reimplementation of a language feature".

Of course, you only ever do this when you want subtly different behavior than the language provides, so I think your larger point still stands.
"If I was "Matt" in the article, and if the author was my best friend, and a very important one at that, I would rather divorce my wife than move, if the move would endanger the friendship I had with the author".

Wow that's taking it to one extreme. What if this job was extremely rewarding financially for your wive or turned out to be what she really wanted to do for years? Would you not support her in this endeavour?

I think true, lasting male friendship should not necessarily imply frequent meetings among friends, but it should definitely entail something along the lines of "I've got your back, and I know you've got mine buddy". Also a lot of things in male friendship do not need to be explicitly communicated unlike female friendship (No need for endless text/messages saying "I love you man!").

It's very important to have friends with whom you share common interests and activities, but they are not necessarily your best friends. Your best friends are generally the ones you've known for decade(s) and regardless of where they are , will be ready to jump in a field of fire with you and come to your aid when times are tough. There's an unwritten contract among best friends; there's an unpronounced oath among men who hold each other in high esteem.
I'm pretty sure I read this last week and it wasn't behind a paywall. Maybe just me. I (along with another developer) spent some time developing an MSN client in VB6 (and later, JS/HTML in Mozilla XULRunner) and quite frankly, it felt like a losing battle trying to keep up with the protocol changes. By the time we were ready to release our MSNP7 version, MSNP9 was out and they were revoking access to earlier versions.
where is this Rails train going? it used to be cool, but it looks like it's heading towards the chasm now.

posts like this just encourage my opinion about the Merb merge with Rails being a disaster which helped Rails transform from "PHP in Ruby" to something beautiful to work with, while leading to self-destruction of Merb.
Rails gained a lot of traction and is now abandoning any good decision Yehuda and other great developers made.

this post simply sums up to: "I don't know how to test-first Rails applications, and I've invented Rails. we're abandoning test-first." admitting you have a problem is a first step in fixing it, but this is not going to fix it in the long run.
I bet the industry makes a lot of difference too. I worked in an MDF factory in North Carolina for a while, and everyone there agreed on 0700 to 1530 for the standard work day. My impression is that people with desk jobs like to sleep in a little later.

Now, as a graduate student in Boston I get in by 0730 every day mostly to avoid traffic. If I sleep in by a half hour it takes twice as long to get to work.
There are a lot of JavaScript frameworks around build by Java developers that couldn't be bothered to check what the language they are working with is about and how it works.

Thus they went and tried to "fix" JavaScript by trying to make it more Java like and thus unleashed abominations such as Dojo or Prototype.js upon the world.

God have mercy on their souls.
"Aw man, I need to install X11 to run this application?"
That stuff is nice, but this phone is significantly newer (as far as mobile phone go). It looks like the Nexus 6 is coming out in November. I would expect it to have similar specs.
Scientist: Babies cry at night to prevent conception of additional sibling
The irony is that that attitude is something you see from rails people about anything that's currently fashionable in the rails world. And I think they picked it up from DHH himself. You didn't get the same kind of TDD zealotry among e.g. Django people.
Dependency injection is more like dynamic scoping, whereas most formal parameters are lexically scoped.
3100 mAh shall actually be around 2 days of semi-heavy use. Owning Nexus 4 and 5, they both exceed two days of normal use or 1 day of heavy use, but the advertised oneplus one is going to have extraordinarly larger battery.

So I would say, expect it last two full days as long as you are not overly heavy mobile user.

Yes, not two weeks, but dumbphones never lasted two weeks back these days. Honestly the new smartphones are finally catching up with reasonable battery life expectations than two years ago.
> Except the first one is much more readable.

I disagree, especially in the presence of syntax highlighting editors.

String interpolation would be a redundant alternative to existing mechanisms (the above plus text/template for longer strings) and just make parsing more complex. I don't think it would fit in well with Go's philosophy of providing pleasant, minimalistic syntax.
Espresso Logic release new product "Live Browser"
Interesting. I agree with everything you wrote until the last sentence. I think he made some great arguments against TDD, but none against unit testing.
Yes let's move towards more coarse grained tests so we can lets the fine grained subtle bugs slip through. You know stuff like heartbleed. Theres a good idea.

To be fair a lot of unit test regimes wouldn't have caught something like heartbleed. Specifically cause it's a security issue and not necessarily a functional issue. But the point is software is damn complex and easy to screw up.

Maybe rather than doing ultimately less test (system instead of unit). We should be slowing down doing even more test at ALL levels (unit, system, GUI, security, performance, whatever) and building something to the best of our abilities. Or does that even matter anymore in the MVP build and sell quick software world?
I really am not seeing a problem anywhere. OO and the structure that follows from it, which is what ends up being seen in this instance, seems like a perfectly reasonable way to write these programs. Programming in an inherently object-based thing like the DOM without objects.. why?
Ok, now try maintaining that when there are 15 types of cars and cars are used in dozens of services. You're imperatively expressing a dependency graph that you could (and would benefit from) defining declaratively at a larger scale.

I'd recommend reading the user guide for Guice for balance before you respond. It's worth seeing how nice DI can be.
Not one number in this "alternative look". IPOs are about valuation, use of proceeds, execution to date, and business plan. It seems to me that many capital markets observers keep having a creationism point of view when justifying valuations.
Why Consider Puerto Rico for your Nearshore Software Development [Infographic]
Time-lapse video shows powerful asteroids strike Earth with surprising frequency
Sorry, you only get 9/10 from me, not enough swearing.
no power of will?
The single thing that really stands out for me in the pricing:

16G $299
64G $349

$50 for 64G of high quality flash memory at retail price actually sounds reasonable!
Sheffield team show simplicity is key to co-operative robots
obfuscating mathematical and computational concepts while making them no less hard

It seems to me that what makes some programming tools better than other is that they hide mathematical and computational complexity while making solving problems easier - nothing is going to make the computationally hard or intractable not hard or intractable.

Attempts to hide computational and mathematical complexity is pretty much the theme for a whole history of programming languages. It certainly is its genesis story -

patch cords ->
machine code ->
assembly ->
high_level_languages ->

at which point the history of debates over programming languages begins, and it seems to me that this debate is largely because what I call 'hiding computational and mathematical complexity' you are free to say obfuscates it. It's how we get the yin and yang of C and Scheme making 70's scene - malloc and and full lexical scoping both simplify someone's life and make someone's unbearable.

I always know that there's a bad OOP example when automobiles are involved. It means it's a marketing piece not a tutorial - managers have cars and as a lowest common denominator of technical knowledge know they have four wheels, provided we ignore the one in the trunk. In other words, we've already lost because the person writing the explanation doesn't know the difference between hiding complexity and obfuscating it [How many cylinders in a Mazda Rx-8? Where does the Leaf fit in?].

On the flip side, what can we expect? Math is hard for a lot of people because it builds sequentially. Teenage hormonal distractions have probably prevented more people from moving beyond ciphering to algebra and beyond than anything save for access to educational resources.

FactoryProviderProviderProviders in the form of frameworks don't necessarily require understanding of higher order functions - like garbage collection, some lazy programmer wrote a program to handle it, and this turns out to be useful because people can use it without really understanding what it is, and being able to use things which are not computationally understood is pretty much the driving force behind the rise of OOP - how many people talk about dispatch when discussing an object's methods?

OOP is a sexier Cobol - cars and their wheels makes for more interesting story than employee records. Even better, outside of the automobile industry, there aren't going to be pointed questions related to domain knowledge (a real risk when discussing employee records with a business person). This and the fact that OOP code is less accessible to the non-programmer than Cobol [which was designed for the boss to follow] gives us Java in any language.

Determining if the conceptual merger of Java and JavaScript described by the author is ironic is left as an exercise for the reader.
Can you recommend a low-cost voice/data carrier in the US for this phone?
http://www.paintballsentrygun.com/ might get you most of the way.

"On this site we have published complete directions on how to make your own sentry gun, which autonomously tracks, aims, and shoots at targets..."
Green threads in the browser in 20 lines of Wat
IME, it gets pretty laggy beyond a few hundred svg elements. The catch to using canvas with d3 is that you lose the ability to bind event handlers to the canvas "elements" (since on a canvas they're not DOM elements, just pixels).

For my latest project I used a kineticjs canvas to get handlers on the canvas shapes. That's positioned on top of a d3-bound svg container. Best of both worlds, reasonable speed up to a couple thousand canvas shapes. Though it was quite tricky getting the same input events to trigger separate handlers on sibling dom elements. (Can't just let the events bubble up unless you make the canvas a child of the svg or vice-versa, but that approach creates more problems.)
Internet to inner-net: what is needed to open source wearable tech
It might be due to its linkbait title :/
Ah that makes sense. Thanks!!
the example code is in java...
Makes sense to clone 2048 by adding it to another cloned game.
A factory and curried function are quite different concepts even if some functionality overlaps. Ditto with tree walking patterns and visitors. Abuse is quite common, because many people are exposed to one and not the other, so use the name hey know other than the one they don't know. Naturally human.
While the idea of testing is good, TDD is so full of stupid quirks and BS disguised as "best practices" it's not even funny

These often result in slow (and sometimes useless) tests. If you want to use TDD to have more time at the foosball table, great

Tests that only test one thing? So I have 30% tests/condition check (or less) and the rest as boilerplate?

"and I do not write software test-first"

Me neither. It's idiotic

Also, TDD fanatics have a tendency of building software that has great coverage and thousands of tests, but fail the simplest of smoke tests.

The world has not had TDD for a long time, and software got delivered. (And sometimes much more stable and durable than today's "one update per week" software)
You'd be surprised how far rote memorization and Google along with a little cheating can get you.

I have a friend currently finishing up his third year for his CS degree. I've tried helping him for the entire time, but he really just doesn't give a damn enough to actually learn. He somehow passes all of the tests, but I know for a fact he could not pass FizzBuzz right now. I know. I've given it to him and watched him completely fail to even decompose the problem let alone start working on a solution.
'They fulfill the goal of "just buy it" or "just install it" and it will do _everything_ a manager or team thinks of.'

That's really not how SAP or any of the Dynamics products get implemented...

Actually, ERP systems are a good example of applications where the complexity pretty much comes from the requirements - they tend to have staggeringly long lists of things they must do. I wouldn't knock SAP or any of the Dynamics products - they are complex because they have to be.
Fair point, but that makes DI a really poor implementation of dynamic scoping.
CloudPatrol: Helping marketers not get fired.
Another case of "I don't understand something so I'm going to just say it's too complex and stupid". The author completely misses the point of service injection in Angular, and then goes on to offer a simpler "solution" that doesn't even remotely do what service injection is trying to do.

Here's the thing - Inversion of Control exists for a reason. Once your codebase gets to a certain size it becomes far, far more manageable to work with loosely coupled components that have no direct knowledge of each other.

These abstractions are a good thing. Lord knows how many projects I've had to fix because some idiot decided that "Architecture" was just some silly crusty of enterprise thing, and "Frameworks" are too opinionated - so instead they decide to ignore 50 years of industry conventions and write a spaghetti code pile of shit (But at least there are no factories!)

Whether you're using procedural, functional, or object-orientated style - A large codebase is still going to be unmaintainable if you don't understand how to write loosely coupled components. (More specifically, don't write a large program - write lots of small ones and compose them together).
The secret to break through a SaaS growth plateau
http://play.golang.org/p/DdwCOZwiCk
Whilst I'm generally pro-TDD (and personally haven't seen or experienced any snobbery against folks who are not), I can see how test-first can seem grating to people. However, I would say TDD, a long with a more decoupled architecture, has a primary advantage over system-test only; division of labour. By not relying on databases or web-services to be implemented, we can work more in parallel, as long as the interfaces to these external systems are stable. If you only have system tests, you have to work in sequence.
TDD is so prevalent in the Rails community, it will be interesting to see what happens now that their leader has discredited all the benefits of it.
The "alternative" refers to the fact that it is not just an overview thats been copied and pasted from the S1 form, but more a speculative look at what the information detailed implies for their future.
Hear, hear. Dogmatic adherence to any system is dangerous. It goes along with being dogmatic. It's important for developers to read what others have done, see how others have solved problems and stand on the shoulders of giants before thinking for themselves, instead of just blindly accepting "best practice" as the best practice.

What I like to do with TDD is use it whenever it's the quickest way to develop something with a level of confidence that is appropriate to the situation.

If I'm creating an HTTP API and someone else is writing the front-end, I'll create unit tests that spin up my API and make requests to it to ensure I get the correct responses.

If I'm in the middle of a codebase somewhere and there's a function which is only ever hit after a bunch of others things, I'll probably write a few tests for that, too.

Just like religious dogma, we are free to pick-and-choose what we do with TDD, when we feel it's most appropriate. Of course, don't overdo it to the point where the code suffers for it.
The place I have seen with the strongest custom about work hours is Japan. I spent a few days in Tokyo, and everyone always talks about the famous "Tokyo Rush Hour", so we got up early and went for a walk through the city. My wife and I went and looked at the fish market at about 7:30, and had breakfast around 8 and the streets were empty. At about 8:20 there were a few people out, but not many. Then around 8:30 it started to get crowded. By 8:40 the streets were packed, people were cramming cheek to cheek on the subway, and we had to find an out of the way place to watch so that we didn't get trampled.

Then, at 9am, everything went silent. The intersections that were filled with people a few minutes earlier were vacant, and you could see just one or two other people on the street, like a women carrying her shoes and sprinting down the sidewalk, for example.

Japan has a very strict society, and it appears that part of that is 90% of the people have to show up at work at exactly 9am, and not a minute earlier or later. I would much rather show up a half hour early and enjoy one of the easiest commutes of any major city.
https://gist.github.com/ImJasonH/7791518
That is not true. If you bought a bigger battery, you could have 3 weeks 10 years ago (I had). And even without, 1-2 for a mobile phone was normal.
Business is a skill you can learn. It's not something you have to suck at just because you're also good at talking to computers. Remember humans are like very inefficient computers that you need to learn to communicate with to get anything done.
Well, it's technically correct. The sense I get is that most people aim their "generic" comments at the 95% (straight, cis, etc). Because reality, in a statistical sense, is heteronormative. But being inclusive is kind as well. There's no exact answer - if you are 100% inclusive, people scoff at you being "politically correct". If you're not, different people get offended.
I don't know how old your dad is but I suggest he go to the local senior center.
In case you haven't noticed, we are running out of IPv4 addresses. CGNAT for v4 is inevitable one way or another. That is why we have IPv6. At least with DS-lite there is only one layer of NAT, compared to full dual-stack which usually implies two layers of NAT (CPE and CG). But all that shouldn't matter that much when you have nice unobstructed end-to-end connectivity with IPv6.
I do run Ubuntu (13.10 32-bit), but I don't see any effect.

$ sudo pipelight-plugin --enable unity3d
[sudo] password for nb:
Plugin unity3d is now enabled

No new extension was added to Chrome. How am I supposed to check whether Unity works?
This post is not a constructive discussion, it's ranting. Ranting is tiresome.
The problem is that people think test driven design leads to good design. It does not. It does not even lead to design at all. All it does is create testable code. This code might have good design, or it might not.
> A machine that only answers to other machines in the same organization should be assigned an address in the 10.0.0.0/8 range. If the organization is not large, even 192.168.0.0/16 would do. In fact, many people would argue that assigning public IP addresses to intranet resources is very bad for security.

That's a horrible hack and those people are wrong. Separate your concerns; addresses for addressing, firewalls for firewalling. Using private addresses adds extra complications; what if someone's home network uses the same range and they want to connect to your VPN? What if you merge with another company that's using the same range? What if you want to use FTP or SIP or any other protocol that uses the internet the way it was intended to connect to a server in a different office, are your packets going to make it through or not? You'll observe that private addresses have been deliberately left out of IPv6, for good reason.