Recent submissions

Comment · 8 years ago
Pro-tip: do an "experiment" with blockchain (built in house to keep it cheap) so they can tell their golf buddies they're looking into it. Make sure it's compared to a sane solution, because then they can feel superior for having "insider knowledge" that it's pointless.
Comment · 8 years ago
As part of my job, I often have to convince business folks that they don't need to buy a fucking private blockchain (from IBM of course, because they're old enough to think that no one ever got fired for buying IBM). This is very close to the arguments I make, and adds some excellent, articulate points!
Comment · 8 years ago
Having been addicted to prescription pills, and currently being prescribed (and presumably dependent on) antidepressants, I think there are a few points that make the distinction abundantly clear:

1. When I consider stopping antidepressants, I'm not filled with anything like the dread I was when I thought about giving up the addictive pills.

2. I forget to take my antidepressants sometimes. I forget to refill the prescription sometimes.

3. I have never had any desire to take more than the prescribed dose of my antidepressants.

It's an important distinction, and unfortunately one that folks in the recovery community sometimes miss. In my experience the above characterization usually brings it home much better than some heavily medicalized description of addiction vs dependency.

Comment · 8 years ago
Anyone know what "triadic arguments" means in this context? Is it a typo of variadic?

  Some C features are still not supported by dffi (but will be in future releases):
  
     * C structures with bitfields
     * functions with triadic arguments
Comment · 8 years ago
> I may take you up on that offer when I can muster up the courage. Thank you.

Please do - it's always a pleasure to help someone out of a bad situation that I've been in. And remember, fear is a prison without walls - you just have to make a decision to walk through that fear, and you're free.

Comment · 8 years ago
You sure you're not me? I got into coding seriously in college after I started to take adderall to help study, and ended up making a career of it. I was absolutely terrified of quitting, because I felt like I couldn't do the one thing I was good at without it. I tried quitting and lost jobs over it, several times. It got to a point where I couldn't function as a human without it - I'd just sit in bed and feel sorry for myself. My addiction progressed to needing more than I could convince any doctor to prescribe, so I started getting more in various illegal ways.

I've been off the stuff for about 4 years, and I don't miss it at all. I'm actually a much better programmer without it - I don't get sucked into unimportant details, I have a more realistic sense of what I can and can't accomplish, and I'm more creative. More to the point, I have a life outside of a little bottle of pills now.

I got off of it after talking to some people who'd also gotten off - this helped alleviate my fears that I would have to give up my sweet programming career, and re-framed the problem as a matter of underused and atrophied motivation and willpower. It wasn't easy, but with a lot of love and support I managed to quit for good.

Hit me up if you want to talk - jonathan dot j dot mason, gmail.

Comment · 8 years ago
Hey they finally fixed the issue with SecureRandom using OpenSSL instead of the OS CSPRNG implementation!

I worked for a company a few years ago that made security software, with Ruby as a primary language, and this caused no end of frustration...

Comment · 9 years ago
I'm with you 100% that this is silly, show-off-y code golf at its worst. The fact that its purporting to generate something a bit sensitive (why else would you use the awkward `crypto.getRandomValues` interface?) is especially troublesome - sensitive code should be clear at all costs.

I spent a bit longer than 30 seconds looking at it though, and I think the 8 is actually significant - according to the RFC,

> "Set the two most significant bits (bits 6 and 7) of the clock_seq_hi_and_reserved to zero and one, respectively."

The right shift by `c / 4` seems to be taking care of this, at least if JavaScript's shift operator works the way I think it does.

The `1`s are to facilitate the goofy string creation trick.

The fact that there's some discussion around the meaning of the code on HN is a bad thing, of course!

Comment · 9 years ago
I am extremely stoked that a huge sample of 17 people have decided to upvote my comment ;-)
Comment · 9 years ago
I think that a small sample size is mostly an indicator that one needs to treat the results with far greater caution.

Effect size is very important in this. To continue your grad student murder example, it's completely trivial to determine which plant a student was given, based on whether they are dead or not. It becomes trickier if you measured something a bit less cut-and-dry, such as the incidence of headaches, or variance in a few voxels of a noisy MRI.

Comment · 9 years ago
17 subjects per group is extremely small.

Looking at it either from a machine learning or statistical point of view, using such a small sample is problematic.

This is the chronic issue with fMRI studies, since administering an fMRI is extremely expensive, and has led to some very difficult to reproduce results in the field.

Comment · 9 years ago
I got massively addicted to drugs and alcohol in college. Flunked out and bounced around through various stages of homelessness and unemployment, putting my programming skills to use to score a few bucks when I could stay sober long enough, then typically getting fired. I spent most of my 20s falling to deeper and deeper bottoms before I started to take recovery seriously. I finally "got it" by diving head first into 12-step programs (not for everyone, YMMV, etc).

Tomorrow I'll have 3 years clean and sober. I have a sick job (even by HN standards), wonderful relationships, more money than I know what to do with, a credit score that's slowly recovering, friends who actually give a fuck about me, and all that good stuff that I think a lot of us take for granted.

Recovery works, folks.

Comment · 9 years ago
TL;DR; tooling is improving rapidly, and while this AI boom will someday end, we'll be left with tools to incorporate the things that do work in our everyday work.

Working for a "digital innovation lab" where a big part of my job is sorting out things that developers can actually use to make cool products from Gartner report buzzword hell, I have a few thoughts about this.

Historically, AI has seen boom and bust cycles. AI, unlike other buzzword technologies, has a large cultural mythos about it - Asimov didn't write "I, EC2 Instance", after all. Thus, non-technical people have very strong and often unrealistic set of expectations around AI, so every time there are technological advances, people expect that general AI is right around the corner, and are disappointed when it doesn't materialize. Right now, we're experiencing a boom cycle as a result of the emergence of deep learning techniques. After every boom, funding dries up and investors loose interest, but the techniques that really work stick around and become part of a developers everyday toolkit.

Like all "black sorcery" technologies, AI has a ways to go in terms of building convenient tooling. Tensorflow is a huge improvement over writing low level CUDA code, but it's still too low level for folks without a strong background in mathematics and machine learning. That said, it's been improving in usability, documentation, and tooling, and just a couple of weeks I was part of a hackathon where we turned their pet recognition demo[1] into software to detect objects of interest to my company in satellite images.

At an even higher level are a number of startups (such as Clarifai[2]) that offer AI-as-a-service. In Clarifai's case, you can train your own image recognition models and apply them with a few lines in your favorite programming language (yeah, yeah, I'm shilling them a bit, but I really like their product ;-).

So at the end of the day, I think we'll all be building various kinds of AI into our products in the not-so-distant future, but you won't really need to go deep into tensorflow and similarly low level tools to do so.

[1] https://github.com/tensorflow/models/blob/master/object_dete...

[2] https://clarifai.com/developer/quick-start

Comment · 9 years ago
Thermal regulation is the most important difference, followed by low depth of discharge.

There are also some (rather weak) reports that if you take the individual 18650 cells out of a tesla battery they last significantly longer than the NCA 18650s you can actually buy from Panasonic, which indicates that they might made to better manufacturing tolerances or something, but it's really all about Tesla's treating the batteries much better during use.

Comment · 9 years ago
I've recently had to become pretty familiar with this subject for work, and your comment is only partially correct.

Li-Ion battery degradation is generally modeled as two (roughly additive) components, called calendar and cycle aging. Calendar aging is what you're talking about in your comment - it's basically determined by the temperature and state of charge. Both of these impact the rate of chemical processes that lead to loss of lithium and active material. This is what happens when the battery is sitting on the shelf.

Cycle aging, on the other hand, happens when you charge or discharge the battery and is driven mostly by the actual volume change in the anode and cathode when they get lithiated (it's quite significant, up to 15% or so in some materials). This introduces mechanical stress, which can break the protective film that forms between the electrodes and electrolyte and allow chemical degradation to proceed at a faster rate. The degree of mechanical stress is mostly determined by the depth of discharge, although rate of charge and discharge is also believed to be important. Cycle degradation is also impacted by the temperature at which the battery is cycled, in a similar way to calendar aging.

With high temperature variance (low temperatures will wreck your batteries too, and I can't recommend keeping them at 5C), calendar aging is the dominant mode. This is absolutely the case with cell phone batteries. However, electric vehicles, especially higher end ones like the Tesla, have an active cooling system that keeps the battery at a constant temperature, even when the car is "off". This is why many EVB warranties will be voided if you let them run out of charge for more than 14 days - at that point, the cooling system isn't working and your poor battery is at the mercy of the elements.

Under closely controlled temperatures, cycle aging is the most important factor, and it's dominated by depth of discharge. If you drain the battery as far as it will allow you every day, it's going to be hosed. If you only go down to about 80% of the allowed charge every other day, it'll last for quite a while. These numbers are roughly correlated, obviously, with the mileage on the car, but the relationship is not simple, and I'd caution against considering mileage to be a good determinant of battery degradation.

Some good sources if you want to learn more:

A fairly simple model of degradation (ignores charge/discharge rate): https://www.researchgate.net/publication/303890624_Modeling_...

A thesis on the subject, goes into great detail and has an excellent bibliography: http://webfiles.portal.chalmers.se/et/Lic/JensGroot.pdf

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton