skysight-inc/HackerNews huggingface dataset:
> the language is perfect in its current form

It works really well in its current form, that is probably the general consensous.

> additional features are a source of evil

Some of us have walked down that path before (e.g. Perl, Scala) and think we have seen the light (or at least the darkness).

> up until the day when they are added, in which case they are suddenly evidence of the language's superiority

That sounded very much like flamebait. Could you name an example of a feature added to Go that was previously considered evil and then as evidence of Go's superiority?
Binary Options Trading Strategy Copy This and Earn Residual
Large companies outside the EU and US have done this for years. It's an old cat and mouse game.

Not many people work within such strict legal frameworks like that.
This article is hilarious. If you want to see why TDD, unit testing, isolation, etc. are important, a Rails app written the "Rails Way" is the first place you should look.

They all look the same. They start out with great tests, verifying that the simplest CRUD operations are covered. Then as the changes come, the tests fade away. Their big browser-driven tests are so slow, brittle, and difficult, the question of "should we test this?" becomes paramount as they try to convince themselves that their code doesn't need tests. And even the most ardent TDD proponents and green-band wearers are suffocated as they have to admit that, yes, for the business' sake we cannot spend days building a test harness to test if a new field is required.

I hope this article is the myth-buster to the fantasy world that the Rails community takes testing seriously.
Ask HN: Do you believe Acompli, Gusto or Mailcloud can really improve email?
https://www.acompli.com/
http://gustoemail.com/
http://mailcloud.com/

All those app seems to be offering some cool features especially for extensive users, like better file management or calendar integration.
Do you believe it is a proper evolution? If not why?
There are plenty of restaurants, coffee shops, grocery stories, and schools in St. Louis that open before 8am, and they make up a substantial proportion of St. Louis's total employment, as do other early-rising occupations like construction and healthcare. I could believe that corporate office jobs typically start around 8:00 to 8:30, but the median could still be earlier than that if you include all jobs.
Our company has been using Gitlab since Dec 2012, we had a small team and small code base back then. While searching for a good inhouse github replacement I found GitLab had what I wanted and was worth the time effort. It has been nice to see the evolution and all the features available now.
No SD card? I'm out.

If they added that, I would get one, the price is amazing - although I'd flash a default CM image over it to get rid of that metro theme they've added.
Hey this looks impressive. Something I can use to end arguments as well where can I deliver feedback once I start using it? Cheers
Yah but banking sucks as an eventual consistency problem. Sure there are processes to go back and solve conflicts, but they suck too.

Part of the reason we can't transfer money instantly between two accounts in the USA is due to sorting out eventual consistency. Federal guidelines on transfer intentionally make it a slow process so the manual processes can catch up.
I own one. I prefer the Raspberry Pi.

- Running Android seems .. useless without a touch device. Tried it, was basically useless for me.

- Running various Linux distributions was not nice either:

* (Fixable) The community projects feel a lot less polished than anything the Pi has

* (Unfixable) The HDMI port sucks. On all TVs I connected it to I have under-/overscan issues. There are no boot options similar to the Pi that allow me to fix that. The IRC channel suggested to 'Fix the TV'...

Looks nice, cheap, interesting specs, but collects dust over here.
The first two apply to Go and Java, the last only to Java since Go hasn't added major features recently.

>> additional features are a source of evil

> Some of us have walked down that path before (e.g. Perl, Scala) and think we have seen the light (or at least the darkness).

We've walked down that path and have been very happy and productive with Scala. Each to his own I guess.
ActiveRecord also showed up in Martin Fowler P of EAA book in 2004: http://martinfowler.com/eaaCatalog/activeRecord.html

I think somewhere in that book (Forewords or preface or whatnot) he also mentioned DHH's help/contribution to the book.

As much as Rails community hates Enterprise, lots of patterns that Rails was built upon showed up in that book as gulp "Enterprise" patterns gulp
Eventual consistency violates the principle of least surprise.

"Oh you hit the save button? Yah, we'll get to that."
I consider myself both a business guy and a programmer. But I'm probably different from most of the people here on HN in that I see myself as a business guy first and a programmer second. My day job is very business-focused (albeit with a technology bent to it) and I hack as a hobby; I've never been a professional developer. I do find that rolling up my sleeves and taking on a small part of a project is a good way to get the guys who work for me to see me as more than a PHB barking orders.

I don't feel the skill sets are mutually exclusive: these days, a good business person should have a deep understanding of the technology. A lot of the approach you take to problems is the same as well: when doing a financial analysis of a company, I often treat the company like a complex system. Business units are modules, projects are data objects and budgets are your resource constraints. Enterprise architecture (i.e. how a business is structured) is the same skill set as technical architecture, only you understand a bit more about motivating people.

Honestly, finding both in one person is rare though. Too many business people go the PHB route and intentionally are ignorant about the details so they can be "big picture guys". Too many programmers just tunnel-vision on technical problems without understanding or caring why things like metrics and reporting are important. Business guys are terrified of being too specialized and technical guys don't want to be "that guy" who doesn't understand anything. It's a hard niche to put yourself in though.
To the OP: did you write http libraries in other languages or rust-http is your first experience?
If I had to choose, I'd pick string interpolation.

i += 1 means an extra line, but that extra line is very clear.

Ternary vs an if-else arguably loses on clarity except for the simplest of cases.

"Today's date is #{date}. Your balance on account #{account.Number} is #{account.Balance}"

"Today's date is " + date + " Your balance on account " + account.Number + " is " + account.Balance

The second is a mess of +'s and "'s to me, not to mention the awkwardness of formatting spaces before and after each quote. The first, you write a sentence and plug in the variables where they belong.

Not saying you're wrong, just what I would choose.
These /8's have been historically been used internally there's no reason they should be handed back. Handing them back would just prolong the migration to IPv6 for limited benefit.

I imagine the only reason you would use a IPv6 private address is if you didn't have allocated global ones. It's just replacing no chance of collision with some chance of collision.
The Bitcoin Fluid Dispenser II [video]
You built a poor application, then rebuilt it - one would expect the second one to be better no matter what frameworks you used. I still believe I could do it faster and end up with a more maintainable code base.

The tools I use to keep my code maintainable are good practices, frequent refactoring, and clear thought. No library can replace those. Why do you need a 2 way binding to take care of showing and hiding elements? Only a 1-way binding is required. I am currently working on an app that uses Knockout and we are having horrible performances issues - all of these 2-way bindings are checking for everything all the time. There are fixes for this - fixes that would not be needed if we didn't build it with duplo.
And yet, Go (and other modern languages) wouldn't look the way they did if it wasn't for Java.
This is not meant to be snarky...

...When someone has a bunch invested (time) in a thing, it's understandable (not necessarily justifiable) to be defensive about anything that challenges that thing.
...or shotgunning, and trying a lot of weak leads at once.
Yeah. I love the idea/concept though.
WinJS 2.1 Available
turn off data connections and wifi and you can get a couple of days worth of battery life.
>But consciousness is by definition a non-material phenomenon, so that's the wrong approach.

Going back to this: I'm not even sure what this means. If you assume you can't understand consciousness through material means then you've simply defined yourself into a paradox. This is an uninteresting and unscientific take and it gets us exactly nowhere.

It's pretty obvious that consciousness does not exist in any singular unit in the brain (we probably would have found it by now otherwise). Consciousness is a property of some non-trivial subset of the units of the brain--at least this is what our current understanding leads us to believe (consciousness is within the brain and its not any singular unit). To characterize this as "non-material" again is a presumption that is not warranted.

Your only reason for treating the substance of consciousness as something non-material is because you simply can't imagine that a first-person experience could be derived from material processes. There is no reason to think this at all.
I actually used to work for a company that developed tools for administrating and interpreting DISC assessments. It's actually really interesting stuff - we all tend to have some assumption at some level that other people think like us, value the same things that we do, and have the same reactions to a given situation that we do. DISC asserts otherwise - just because I want to be treated one way doesn't mean that you want to be treated that way, and by understanding those differences, we can eliminate friction in communication.

Once you can learn to read how others want to be treated and know how to modify your own interactions with them accordingly, your ability to successfully interact with a wide variety of people vastly improves. It seems obvious and handwavey, but in my experience, the vast majority of tense relationships or awkward interpersonal interactions are because of a failure of two people to understand each other. Even if they're both behaving in the way they'd want to be treated, that doesn't mean that they're treating the other person as they'd want to be treated.
> I'm as sceptical as the next guy about frameworks, hate "enterprise" with a fiery passion and I escaped academia before it fried my brain.

Evidently not, can't say, perhaps not.
The Platinum rule does however require that you know someone else's preferences, which is harder when you are not married to them.

I default to treating people how my mental model of a "normal person" wants to be treated. For example, most people in most circumstances want minimal interaction with strangers. I then modify that by what I can vaguely infer about their preferences based on their background. For example, women going to be not just annoyed, but creeped out by random strangers. I then modify that based on setting: at a conference, people are far more interested in meeting new people. I then try to pay attention to their body language, tone of voice, and words to see if I can read anything about them as an individual. If a person looks alert and open-stanced, they are probably more interested in meeting people. And of course, if it is non-awkward, I'll just ask them about their preferences.
Customizing Android ListView Rows by Subclassing
Yes thanks, any feedback is very much welcome!
add a social hobby (e.g. golf) to that list for some out of house time
You can call yourselves "South Americans" though, and everybody would understand.

Not all taxonomies consider "America" as one continent. In geography school we were taught of North America and South America as different continents. And if you check Wikipedia, you'll see there are several ways to divide the continents, and they cound from 5 to 7 depending on how you look at it, IIRC.

>Another "interesting point" though is that the Indigenous population are still called Indians and the the real Indians are not identified as Asians.

In my corner of Europe we don't consider the "real Indians" as Asians either. Some cultures do, but we prefer to reserve the "Asian" moniker for the far east (Malaysia, China, Indonesia, Japan, Korea etc). I don't see much cultural or historical resemblance between these and Indians.
You need to hire someone like Tom Smykowski, from 'Office Space':

"I deal with the goddamn customers so the engineers don't have to."

http://www.youtube.com/watch?v=nV7u1VBhWCE
I love seeing all of these cheap ARM boards coming on to the market. I am a big fan of the BeagleBone Black but the supply problems recently have had me looking around for an alternative. Unfortunately my project uses the USB device port and there don't seem to be alternatives that offer USB device or OTG support.

Am I the only one who wants OTG support? Or are there boards with USB OTG ports that I have missed?
Does this exist for general opinions? Looks awesome overall.
> it's how you pass them around and use them in a component that has no knowledge of the outside world

You pass it as a function argument.

function needs_to_make_a_car(car_maker, road) {
var car = car_maker()
car.drive_on(road)
}

To which you would probably reply: "But that's exactly what FactoryFactory/DependencyInjection/... pattern is!"

To which we would reply: "Exactly, which are just fancy words for the re-and-re-discovered concept of functional programming."
All these tiny board SoC's are fine and dandy, but as long as they do not have a better I/O (i.e. more bandwidth, read gigabit ethernet speeds) than the RPi; there's no real advantage IMO.

* You can already output HD with the RPi
* You can use (some) codecs at an useful speed (no need for more GHz)
* It's cheap
* It uses almost no power
* You have useful (physical) IO
* (fill in what you like about the RPi)

So what does that leave with the alternatives? More RAM and more processing power. But of what use is it, when you're still limited how fast you can bring data you want to crunch on in and out of the system only at a slow pace?

And if you need a lot of processing power but have only little data; I'm tempted to say that such a small system is the wrong choice anyway.
Using the POSIX standardized utilities and scripting framework.
WHAT DOES IT MEAN TO BE SIMPLE?
10 to 4 with a one hour lunch is my preferred working hours if I'm going to be selling my labor to someone else at least. Unfortunately, American culture doesn't agree with me. Perhaps I should move to France :)
Because now you're introducing an interface when previously you had shared objects all on the server in a single codebase. For example, let's say my JavaScript client works with a "User" object delivered via REST API from the server. Let's say I change Django's User model object to modify some existing attribute. Previously, all my Python code's tests would now use this updated model object and I could simply run my tests and count on finding bugs where things that make use of "User" were broken as a result of the change. But now, with lots of client side code, a whole other JavaScript-based test suite (completely outside Django's) needs to run to make sure the new JSON representation will work.

However, this means I have to not just test the backend Django code, but also the output of the REST service, the interaction between the JavaScript code and REST API, and the internal JavaScript methods that use the User object on the client. You are now dealing with at least two completely independent testing frameworks (one in Python and one in JavaScript). If you want traditional unit tests, you need to mock the API calls and the JSON payloads in both directions. Now you've got to maintain all those mock objects for your tests so that your tests are actually testing real payloads and calls and not outdated versions. Ultimately, the only foolproof way to actually be sure it all works and you didn't miss anything is to actually deploy the whole app together and poke at the full stack through a headless browser test.
The kind of "architecture" that you are talking about that was often postulated under the banners of "Single Responsibility Principle" (a poor rule of thumb in fact) and "design for testability", that results in one-method classes, or classes that do not have any state and pass everything in via method parameters is in fact contradicting basic tenets of OOP like encapsulation and having a reusable domain model - I find it, like DHH, a horrible abomination, even if tests are faster because of it.

There are lots of other ways of dealing with complexity in Rails that do not involve any of this kind of thing. Some of the people who go around talking about DCI and services have problems with basic OO modelling or even with simply writing good methods (it actually takes a fair amount of skill), with Ruby and Rails knowledge, and drowns in complexity not because of Rails default architecture patterns, but because of a general lack of coding skills, lack of developer-PM communication that increases essential complexity, lack of developer-developer communication, NIH, etc. Here is a whole bunch of thing that you can do without introducing "service objects" and all that:

- Extract non-business-logic-related general components like API wrappers, widgets into a Gem, Rails engines, jQuery plugin etc.

- Use existing gems and techniques that concisely encode high-level patterns, like state machines

- Extract common pieces of behaviour into controller or model mixins (concerns)

- Use finer-grain modelling, e.g. introduce value objects (see documentation of composed_of) or simply split models into smaller ones, e.g. instead of having simply a User model, separate User and Profile. Extract very complicated algorithms into separate classes.

- Promote code reuse by taking extra care of having an ultra clean API for crucial domain logic operations - the methods that correspond to those should be listed in one place with brief descriptions, documented in detail where they are defined, have easy to remember names, flexible parameter lists allowing handling of different use cases, clear error signaling and so forth.

- Group related models in modules.

I would like to see one codebase that perfects all the basic coding practices of this kind and yet still has issues with the explosion of complexity. Somehow people manage to write, for example, complicated games spanning several hundreds of thousands of lines of code without introducing LightRayHitSpherePredicateFactories all over the place, and to a large extent I think they do so by mastering the basics of the kind listed above. I would also like to see one codebase that uses DCI or Service Objects religiously that isn't a 100 line TODO list.
The Kindle wink
I agree with you for the most part - what you're describing is rampant abuse by cargo-code programmers that don't know better.

This doesn't mean GoF design patterns are specifically wrong. It's just that they are misused and applied in places they don't belong. When done properly, they should emerge organically as you code without you even realising it (That is to say good design patterns are emergent phenomena in good code, not the other way around).

It also doesn't help that the entire software industry is fixated on single-inheritance OO languages, which tend to encourage ridiculously bad designs.

> It's cheaper and more reliable to chop your product up and write each chunk in whatever separately with no official architectural pattern usage system-wide.

This nails good software design on the head. Don't write large software, write small independent reusable components and combine them together.

This is what dependency injection solves well - When done properly. (If it involves XML or config files it's not done properly).
http://xunitpatterns.com/

That's another book for good tests design. Warning: very thick since it is a "reference" type of book.
And during all that time they were telling us we didn't need them.
Ask HN: what's the highest version number ever seen?
I am wondering, what is the highest version number (years used as versions do not apply) ever seen, before the software name is maybe changed?
You were probably in white-collar jobs. Those tend to have later starting times. Service sector and blue-collar jobs (which make up a large portion of the workforce) frequently have earlier starting times.
>Wouldn't that mean that the code would have a huge performance penalty when running on 32bit hardware?

Or it could just forget 32bit hardware altogether. Even mobile phones are going 64bit already -- and the language will be ready for production in 1-2 years, where even more platforms will be 64bit.

It's not like they have to compromise just to be able to run on some embedded stuff.
Largely because more of the automated integration testing has to be done with a headless browser, e.g. Poltergeist.

If you have no JS in an important area of your site, you can integration test it without a headless browser. Your test process models HTTP requests as simple method calls to the web framework. (E.g. in Rails, you can simulate an HTTP request by sending the appropriate method call to Rack.) The method calls simply return the HTTP response. You can then make assertions against that response, "click links" by sending more method calls based on the links in the response, submit forms in a similar manner, etc.

But if a given part of your app depends on JS, you pretty much have to integration test in a headless browser. Given the state of the tooling, that's just not as convenient as the former approach. Headless browsers tend to be slow as molasses. There are all kinds of weird edge cases, often related to asynchronous stuff. You spend a lot of time debugging tests instead of using tests to find application bugs.

Worst of all, headless browsers still can't truly test that "the user experience is correct." That's because we haven't yet found a way to define correctness. For example, a bug resulting from the interaction of JS and CSS is definitely a bug, and it can utterly break the app. But how do you assert against that? How do define the correct visual state of the UI?
It is. Nevertheless it's still worth pointing this out because there's lots of people who haven't figured that out.