Show HN: Student Status, Automatic Student Verification in Seconds - <AUTHOR> https://studentstat.us <comment><USER2> Why are you using an unrelated quote to make it look like your site has some form of affiliation or recommendation by Wired?

How well does this handle rampant fraud? In the past, whenever we've done any form of educational freebie or discount, there are floods of signups (often IN, BD, LK, ID as most prevalent) that are blatantly fraudulent but with hijacked/stolen .edu emails, occasionally faked course listings with one course. There are a number of badly-written vulnerable webapps, often 2-year unis in the states that seem to allow applicants to get an autogenerated .edu email even before admission or any form of verification.

I see the word AI. What AI, and how?

<comment><AUTHOR> That's a good point, I was debating on whether or not to put that there, but I believe it's under fair use policy for journalism. It's a quote and not a statement of endorsement, but I get why it could seem confusing. The purpose of it was to convey the goal of my service, which is to have companies use students as a core part of their mission, which in turn benefits them in the long run as they convert students to real customers when they get into industry. Thanks for the feedback though, I'll have to think it through more.

For fraud, of course if someone is willing to spend the time to crack the system, they probably will. The point is not to stop the one off attacker, because the implications are just you give a discount to an incorrect person (which you can limit by limiting the deal - for ex. 1 year discount).

AI because it's using OCR and some proprietary checks on the second step. It is more intelligent than it looks.

<comment><USER2> It's not one-off, they usually try to get thousands of accounts and then sell them for $1-2 as the usual thing. This is absolutely something that needs to be stopped.

<comment><AUTHOR> that's a terrific point. i do believe the 2-step check with the document is enough to prevent abuse. i will absolutely consult with a security expert on this when i'm able.

if you are you able to email me at email@example.com more of your concerns i would really appreciate it. in any case, thanks.</comment></comment></comment></comment>


Made a Stack Using AWS API Gateway, AWS Lambda, and Swagger and Want to Share - <AUTHOR>

Hey, all.  I recently transitioned to a new type of stack using Swagger, AWS Lambda and the new AWS API Gateway and it rules so I've put it together in a stack and I'm going to do a live video about it…
It works like this:   You define your API in JSON (Swagger), deploy it instantly using AWS's API Gateway, and write an AWS Lambda function for each API route.
This way, the code for each API route only runs when it's called.  Which is cheaper than paying for a 24/7 web server.  Plus, the code for each API route is totally isolated from all other routes so it's easier to fix stuff rapidly without affecting anything else, and when code breaks, it only affects one API route!
I think this is going to be the new normal for start-ups.  If this sounds cool to you, I'm going to do a live stream this Sunday, July 26, at 5pm PT @ https://www.livecoding.tv/ac360/.  The video will be recorded and available at that link as well (and possibly Youtube). <comment><USER2> Sounds good... I want to know a thing as I understand AWS Lambada thing, is you code your own function for each API, could I use total cli app instead and use one of its functionality... For example if I want to use imagemagik can I use it instead of my own function or not?</comment>


Preliminary NTSB Crash Report of Deadly Arizona Uber Accident [pdf] - <AUTHOR> https://www.ntsb.gov/investigations/AccidentReports/Reports/HWY18MH010-prelim.pdf <comment><USER2> This is a very recent dupe [1] of a thread 3 hours older, with 180+ upvotes and 180+ comments.

[1] [https://news.ycombinator.com/item?id=17144160](https://news.ycombinator.com/item?id=17144160)</comment>


(&) = flip ($) in Haskell - <AUTHOR> http://vemod.net/ampersand

<comment><USER2> This is included in the popular Control.Lens package since it sometimes has natural right-to-left composition. It's still unnatural for 99% of Haskell code you'll see, but (&) = flip ($) seems to be cemented as the "correct" representation now.

It's a wontfix on the language spec itself, though.

<comment><USER3> It was closed with the message: "I'm closing this ticket while the discussion is going on on the libraries list. Please reopen, or open a new ticket, if a positive decision is reached" [1]

The discussion itself [2] is basically bikeshedding at this point.

[1] <http://hackage.haskell.org/trac/ghc/ticket/7434> [2] [http://www.haskell.org/pipermail/libraries/2012-November/018...](http://www.haskell.org/pipermail/libraries/2012-November/018832.html)

I took both of these links directly from lelf's comment in this thread.

</comment></comment><comment><USER4> Yep, except that it is not there.

There was quite a discussion about (&), (|>) and what not on the mailing list. No consensus…

[http://www.haskell.org/pipermail/libraries/2012-November/018...](http://www.haskell.org/pipermail/libraries/2012-November/018832.html)

<http://hackage.haskell.org/trac/ghc/ticket/7434>

<comment><USER5> F# obviously approves |>, but in my software project that has been continually maintained for ten years, we introduced -->. Now re-factoring our project we use |>. It kind of messes with my sight against pattern matching in OCaml though.

</comment></comment><comment><USER6> I guess F# and livescript use |> and <|. I like them better than $ and &.

Like

[3,1,2,3,41,2,4] |> sort (>) |> map \x->x*x

</comment><comment><USER7> while I recognize this is tongue-in-cheek, just as a PSA...

When trying to hack something together, excellent.

When trying to learn a new language, aim for idiomatic usage.

<comment><USER8> Haskell is like Lisp: so expressive that it supports many idiomatic styles of usage, depending on application domain.

</comment></comment><comment><USER9> Diagrams defines # to be reverse function application.

</comment><comment><USER10> I used ¢ as flip ($).

<comment><USER10> I guess this is too heavyweight, after all:

        Prelude GOA> (return [1..]) >>= return . map (^ 2) >>= return . takeWhile (< 64)
        [1,4,9,16,25,36,49]

</comment></comment><comment><USER11> Diagrams uses (#) for this.

</comment><comment><USER8> You'll flip your id

($) = id Except that id works on values and functions, but $ only works on functions.

(&) = flip id

$ is just an less-expressive alias for id that looks prettier (and has different precedence/associativity when used infix)

<comment><USER2> No, not strictly true! ($) has a compiler hack to let it handle impredicativity.

        import Control.Monad.ST

        infix 0 %
        (%) = id

        runST $ return () -- :: ()
        runST % return () -- Type error!

        Couldn't match expected type `forall s. ST s a0'
                    with actual type `m0 a1'
        In the return type of a call of `return'
        In the second argument of `id', namely `(return ())'
        In the expression: runST `id` (return ())</comment></comment>


Literacy may have stolen brain power from other functions - <AUTHOR> http://arstechnica.com/science/news/2010/11/literacy-takes-over-the-brain.ars

<comment><USER2> "Stolen"? Seriously? I suppose the next article I can expect to read is "Why Your Ability To Read Is Just An Illusion".

(I dislike the titles that invoke the "The Thing You Suppose Does X Actually Does Y" like that's a bad thing. The badness is in the supposition, not the deviation from the supposition. What the brain is "supposed" to do is a human construction, not universal truth.)</comment>


Why One Programmer Doesn't Do DevOps Anymore - <AUTHOR> https://lionfacelemonface.wordpress.com/2015/03/08/devops-is-bullshit-why-one-programmer-doesnt-do-it-anymore/ <comment><USER4> Sys Admin/Engineer here. We had it right 15 years ago. You couldn't become an admin unless you started as a programmer. You needed a deep understanding of your OS and good knowledge of C. At that time the devs ("programmers") were less knowledgeable than sys admins. You had to have to skills to analysis, debug and fix their code. When sys admins stopped coding the result was weaker admins. Sys admins ought to code within their domain, engineer, and maintain their systems for performance and high availability. It is long over due that sys admins return to their roots and get ahead of the pack.

<comment><USER5> I'm part of the recent sysadmin generation that had no programming skills and grew up doing what I consider more "application administration." Lots of clicking Next with no real understanding of what to do if that Next button quits working. Stack tracing? Procmon? Miserable understanding of DNS and networking, what's a /24? These were things senior admins knew and used once the tickets went up the chain because customers were screaming.

I was always (well, not always, once I'd proven myself) a senior admin/engineer, now I focus almost purely on AWS automation, and it bums me at out how many admins are completely happy with just being Next button admins who are absolutely AFRAID of touching a bash or zsh shell, or even a Cisco router without the UI.

I suppose it shouldn't bother me, it's done great for my career.

<comment><USER6> Are you talking about sysadmins on Windows? I can't imagine a Linux sysadmin being afraid of bash, zsh or a ios shell. My impression is that knowledge of some combination of bash, perl and python scripting is a basic job requirement.

<comment><USER7> the root of the problem (the idea that sysadmins can't program) might come from the fact that every company whether furniture/clothing store or any other sizable non-tech business needs sysadmins. But only if technology is your core business you need good developers. This probably leads to generalization of sysadmins not knowing their bits/bytes. Sure guys working for ISP's and in datacenters are a different breed but they still get thrown into the same category because of the job-title.

<comment><USER8> I think the problem is, some companies are expecting a sysadmin to be the "IT guy". The one who is only expected to call contractors to fix that recurring network problem, and install enough Windows boxes for the new hires.

</comment></comment></comment></comment></comment><comment><USER9> DevOps as it has been implemented in tons of company _is_ bs.

Its like the "Agile" push that companies thought they could get by buying a tool, and changing nothing else (release schedules, feature based release dates etc).

My favorite way of looking at it is simple - replace the word DevOps with empathy. That is the core of the idea, so lets try it - "Empathy Team", "Empathy Person", "Empathy Engineer".

DevOps is about dev and ops teams communicating and having empathy for the requirements of the other team.

<comment><USER10> > DevOps is about dev and ops teams communicating and having empathy for the > requirements of the other team.

Most posters here don't seem to get it. Most replies appear to be the idea that DevOps means you fire your Ops people and the Developers do Ops previous job and their own Development job as well.

<comment><USER11> Or, in the small company case, you never hire any dedicated ops people to begin with. You have developers fighting fires all day, getting interrupted constantly, causing them to hate their jobs.

<comment><USER12> Small company. We don't have many problems. We have a couple pain points but we fix them over time. When hosts die, it generally doesn't mean anything. There's redundancy in all things. I don't find myself interrupted often.

Previous job had a "Systems" team and a "Database" team. Both were just teams of obstructionists.

"Oh you need something today? Well, if you get a jira ticket made I could look into getting the requirements written up sometime in the next 2 weeks, to get the work assigned out next month."

Not saying that's the norm, but damn I hope I never experience that again.

<comment><USER13>
      Both were just teams of obstructionists.
      "Oh you need something today?
        ... get a jira ticket made
        ... work assigned out next month."

It is possible that you might have a different opinion of the situation if viewed from their perspective. It's likely not deliberate obstructionism, but rather them trying to triage the requests so that they can be most effective across all customers. (It's possible that your ops team did not adequately communicate this to you.)

In my current job, I am the sole developer responsible for maintaining a certain set of our codebase. I have multiple internal customers, each of whom have separate (external) customer-facing needs. I have enough tickets created for three people working full time, so I am constantly having to triage which are the most important.

Part of the solution to this was to have a proposed plan for when to work on things -- I can then say, "Thank you for this well thought out ticket. I will be able to work on that in June." The most important thing is that my users' opinion about the criticality of things does not always match the overall picture, and I am always having to choose which tickets to postpone.

<comment><USER14> This is a good point, but it's a sign of dysfunction. I've seen the case when 50% of the issues are "P1 highest priority" (and most of them forgotten in a week or two). People making requests need to get some idea about what development effort (and maintenance!) costs. I don't know a good way to do this, except to be in a very small company.

</comment></comment></comment></comment></comment></comment><comment><USER15> As a "DevOps Engineer" (use to be called Sys Admin) I feel a lot of posters here are using the term wrong.

A lot of us old sys admins are now calling ourselves devops because times are changing. To me devops isn't about taking a developer who likes ops to save some money. Its about taking ops out of their walled garden and into the development process. As someone in ops, I'd much rather be part of the development process as I'm the one supporting the code in production.

If its a choice of message queues.. I'd rather have a vote to the one I know about supporting.

It isn't really about cost savings as some companies I've been in I'm one of the highest paid engineers on the team. Its more about bringing ops into the process.

<comment><USER16> In addition to that, I always thought DevOps meant operations people using development practices and tools to automate and simplify their lives? Does it have to be more complex than that?

<comment><USER17> If you take your definition as "ops people who code and automate", you get a really efficient ops team who can orchestrate several hundred or thousand servers.

You still then have a friction point between "dev" and "ops" relating to hand off. Ops could go full PaaS, but more than likely you'll end up with a "cloud" infrastructure where your dev team will have to learn ops, or the traditional model where stuff gets thrown over the fence. Good luck deploying that service because there was no capacity planning and it'll take 6-8 weeks to get hardware from the vendor, regardless of whether ops can rack it and build it in under a day.

It's far better to have an org overlap so that ops is involved in dev planning to help address roadblocks, assist in capacity planning and management, as well as help reduce friction in tasks.

<comment><USER18> But, the purists would reply, if you simply outsource all your hardware to AWS or another place, you don't ned that ops or capacity planning. Until you do. This weekend AWS ran out of i2.2xlarge instances in a particular AZ, for example.

<comment><USER19> Hate to tell ya, but at anything other than the 'prototyping stage', you'll probably need a dedicated OPs guy, AWS or not.

</comment></comment></comment></comment></comment><comment><USER20> From one of the comments:

> It's easier to train a developer to do sane operating procedures than to > teach a sysadmin the developer mindset (testing, revision control, breaking > down to logical units and similar).

Having done both jobs, I don't really think that's true, unless by 'sysadmin' one means the type of low-skill position which resets passwords. A system administrator is responsible for administering a _system_ of hosts and software; his should be a _more_ complex job than a developers. He should be responsible for test systems as well as for production systems; his scripts should live in source control. I'll grant that functional decomposition _may_ not be as vitally important to his work as it is to a normal developers—but then, his scripts will inevitably grow to be pretty complex, so maybe it will be after all.

That doesn't mean that developers are stupid either. Sure, at BigEnterpriseCorp a developer is just a seat-warmer who implements directives like 'add a method to the Foo class which takes two arguments, adds them and returns the result,' but a real developer is a student (whether formally taught or informally self-taught) of computer science; he understands and can choose & implement both algorithms & data structures in order to solve a problem.

A good DevOps hire is going to have some skill in both areas, not as a weak sysadmin and a weak dev, but as a strong sysadmin and a strong dev. A good DevOps team is going to be _more_ skilled (and expensive) than the equivalent dev and ops teams, but it will also be more productive and less error-prone.

If you're trying to build a devops team from Initech, Initron and Initrol low- skill employees, you're probably going to fail. If you're building a devops team to reduce costs, you're probably going to fail. But if you're building a devops team to increase profitability and competitiveness, you may succeed.

<comment><USER21> In the Unix/Linux world, a lot of the Sys Admins I've met have been very strong technically. Knew at least a scripting language and basic C programming. The trend however has been for less and less coding skills and more superficial. Sometimes not even any shell scripting skills.

In the Windows world, a lot of the Sys Admins do not have those skills. It's changing, things like PowerShell and various others are helping, but a lot of Windows Admin are just not that comfortable away from the GUI. I think the comment you refer to is by someone with a Windows dev background. GUIs don't version...

The mainframe world folks tended to be very silo'd (and IBM engineers were never far to hold hands.)

</comment></comment><comment><USER22> So many misconceptions here as to what DevOps is. I think _mugsie_ comes closest with his use of the term "empathy". This is very very close, but I would add one more term "cooperation".

DevOps, when implemented correctly can have enormous, order of magnitude increases in both productivity and quality, but it is not voodoo, despite this almost unbelievable claim. It involves empathy and cooperation and it requires this because in order to implement DevOps in a meaningful way, an organization has to vastly increase communication between "silos". It has to formalize, document and automate as many processes as possible.

DevOps is NOT easy to implement and involves a cultural shift and absolute management buy-in. It is best implemented in small projects, where clear wins can be demonstrated. Use this success to bootstrap the process to bigger projects.

I do agree with the OP that if you have a DevOps team, you are probably not doing DevOps. The whole point of DevOps is to get rid of silo mentality. No more us and them, but all us.

Implemented correctly, everyone is DevOps.

</comment><comment><USER23> It's fascinating how much this engineers experience shares with mine. We both appear to have similar approaches to working with technical systems, that has led to skillsets that are more broad than deep. We've both had interview problems because of this, and we've both ended up in DevOps.

I've also had more or less the exact same experience with DevOps, though with (hopefully) a happier ending. I was on a team working for a client that desperately needed "DevOps-type" things. So I built them, and their infrastructure team ignored them.

Eventually we stopped working with that client, and I was moved to a different organization, where each development team was doing it's own thing, operations-wise, and had no interest in adopting a uniform approach, so my (short) efforts there were also for naught.

But then I had the opportunity to come back to the first client, as their DevOps Manager. Before I took the job, I talked to their current development organization about what their pain points were, and what actions they would be willing to take to alleviate them, and I built a strategy around that. A key part of this strategy was gradually eliminating the need for a DevOps team, as I firmly believe the best application of "DevOps" is as a joint project between Development and Operations to optimize shared processes. Once the friction is minimal, you don't need a team there anymore. So we have a developer embedded in our meetings, and have more or less full control of any infrastructure.

<comment><USER24> I think there is a fundamental disconnect between what DevOps is and the classical business organization structure.

DevOps is not a department and it will not work if it is a department DevOps is a way of doing things to achieve maximum efficiency and everyone on development and operations must embrace it for it to work.

If either development or operations resist the change then either the resisting members should be eliminated or the switch over to the DevOps way aborted.

DevOps doesn't work without cooperation and effort from all team members.

<comment><USER25> So in essence, devops treat every projects as if it was a startup? That is, to hell with departments, managers and lines of communications, one project, one team, one office?

<comment><USER24> Not quite, Managers can be separate, accounts can be separate, advertizing can be separate etc. but Development and Operations must be treated as one unit no separation.

In other words anything that can have a line of communication and still work can stay as it is but in order for DevOps to work development and operations must essentially become one with both developers and sysadmins working together on architecting a flow that works for both of them.

One office and one project is not really a requirement but it helps a lot in the beginning however if you can keep the cooperation a culture alive even working remotely could work.

The key is people who are always willing to learn and try new things and putting effort into change and staying on the same page with their teammates.

<comment><USER26> So who gets the production system and database root passwords?

</comment></comment></comment></comment></comment><comment><USER27> So this is the thing. There are three things that really go against a true "devop" system:

1) cost.

Ops are cheaper than devops, sometimes twice as much. Yes yes, flexibility. But thats a misnomer. If your dev teams are doing donkey sysadmin work, because they don't have the experience, or are up all hours fixing things, you're going to endup with a high staff turn over.

2) division of labour

As a company grows, they can employ more and more specialist staff. This gives them a competative edge as they are able to make nuanced decisions based on skill, or experience. A decent storage admin will be able to build a storage system that will scale relaibly, cheaply and with less downtime than someone who is not a specialist.

3) burn out.

A human is not designed to multitask 14 hours a day. Coding, testing, supporting, infrastructure procuring, for anything other than the smallest company is too much for a single role.

There are great things that come from a devop "culture"; greater personal autonomy. However like all things, its not one size fits all. There is a great deal of arrogance where people assume that a sysadmin never automate anything. or that they can't program.

They can and do, you know why? because they want to carry on searching ebay, scamming $someone boasting about network speed, or just plain getting shitfaced.

<comment><USER28> I was with you until "because they want to carry on searching ebay, scamming $someone boasting about network speed, or just plain getting shitfaced.", but I'm guessing you're just being cheeky.

<comment><USER13> I was thinking it was a BOFH ("Bastard Operator From Hell") reference. [0] The BOFH is a fictional sysadmin who is worse than any you have ever had, in entertaining ways. He basically does exactly the things the OP mentioned, while dealing with clueless management, undeliable vendors, and a Sith Apprentice^W^WYoung Coworker who learned well, and is constantly trying to stab him in the back. He's like a mix between Catbert and Wally. ;)

0: [http://www.theregister.co.uk/2015/02/27/bofh_2015_episode_2/](http://www.theregister.co.uk/2015/02/27/bofh_2015_episode_2/)

</comment></comment></comment><comment><USER29> I am a big believer in DevOps to the point where I often consult to "implement DevOps" at organizations. The frustrating part if that organizations seem to want to create "DevOps Teams" to augment their other teams. An organization cannot have a "Development Team", an "Operations Team", and then a "DevOps Team". DevOps is a set of good principles which help to guide the process of making, releasing, and maintaining good software products. These are by no means the only set of principles and organization should live by, but Developers and Operations should work to implement these principles because it will make their process more efficient. It is certainly not a matter of simply tossing in yet another department full of people and hoping that more cost efficient work gets completed.

When I work with clients the inevitable question comes up: "What Principles should we implement then?" and the answers are usually more questions really. How long does it take developers to set up their working environments and get to coding? How is code tested and prepared for deployment? Are stakeholders feeling secure about deploying this new code to production users? Can we deploy effectively every time without deployment related issues? When something bad happens in production, what is the recovery procedure and how long does it take?

The answers to these questions and many others often show that there are a few issues. First, developers and operations aren't speaking to one another enough and aren't really working together. Second, there is very little trust in the current environment and that lack of trust is made up for by adding more human intervention. Third, there is very little automation and this causes the lack of trust but few people what to change their habits to fix it. And finally, there is such a great divid between engineering and operations that the pains felt by one group and not shared by the other.

DevOps has the principles needed to start to solve these problems. However, we don't need a department to implement those principles. We have enough departments.

<comment><USER30> Well said. I think this is what the author of the OP was also getting at - it's better to grow the culture (while sharing responsibility) where it belongs rather than purchasing it wholesale and shoving it down dev throats.

As an employee of a large software focused corporation that does many of these things right, I had no idea how bad things can get for smaller, newer companies that haven't figured all of this out.

<comment><USER31> Even small companies can have momentum and unanalyzed patterns that are hard to change.

</comment></comment></comment><comment><USER32> Replace DevOps with QA and an equally valid article.

Dedicated QA teams should be avoided unless truly necessary. Otherwise, you have the same problem of developers throwing over under-tested code to a group of separate people that are smart but treated poorly.

A QA guy who loves to write automation gets the same promises... "oh you'll be programming mostly; manually test maybe once a month". But when they get into the door, it's the exact opposite.

Developers should all be passionate about QA (read as: the quality of their product), as well as how their product is actually deployed (read as: executed in the most important of environments--production!).

</comment><comment><USER33> Last month I went to the UK PHP Conference where Jeremy Quinton spoke about DevOps. The biggest take-away I got was:

'Do not set out to create a DevOps team or employ people for that role'

My interpretation was the role simply doesn't exist. If your company has a team of developers and a team of people who keep the wheels turning - in an ideal world you already have a DevOps team as long as they collaborate. If you also employ smart people you will get 'developers that know how to do sysadmn' and 'sysadmins that know how to develop' \- definitely this indeed should be embraced but not expected.

</comment><comment><USER34> Obligatory lusis quote and link...

"Devops means giving a shit about your job enough to not pass the buck. Devops means giving a shit about your job enough to want to learn all the parts and not just your little world.

Developers need to understand infrastructure. Operations people need to understand code. People need to fucking work with each other and not just occupy space next to each other."

[http://blog.lusis.org/blog/2013/06/04/devops-the-title- match...](http://blog.lusis.org/blog/2013/06/04/devops-the-title-match/)

</comment><comment><USER35> >You can't have DevOps and still have separate operations and development teams. Period.

I cannot disagree more. You can't have developers of your product knee deep in DevOps and be effective (at a certain size, smaller teams with less demanding operations needs can).

DevOps should have very clear demarcation of responsibility in an organization. What the OP describes is an blending of responsibilities and that is the root of his problems.

DevOps /is/ operations. It is just that simple. It is design and automation of support systems. Nothing more, nothing less.

<comment><USER36> If 'DevOps' is operations, that what is the point of the term? Ops teams have been doing automation of support systems for a while, so what exactly does it mean to be DevOps? I think that's part of what the OP is getting at, if your fancy 'DevOps' team just ends up being separated and isolated from the dev team you're back at square one, you've accomplished nothing and the same divide exists with a new label.

As someone who works on the dev side, the ops side, and the mixture of the two I feel the OPs pain acutely and have had mixed experiences. People on the dev side need to understand and willing to learn about ops, it's not rocket science and you don't have to be knee deep in it to get the basics down. When ops becomes this black box and becomes a bottleneck is when you start to see dysfunction.

<comment><USER35> >If 'DevOps' is operations, that what is the point of the term?

It is taking more of a gestalt systems approach to the entire support structure. This means more intelligent support programs and treating it like designing and delivering a software project (or, more accurately a series of subprojects) as opposed to a loose amalgam of scripts.

This also requires the product development team to be keenly aware of that support architecture and how their decisions factor into it especially in terms of testing, deployment, and module interactivity.

> Ops teams have been doing automation of support systems for a while, so what > exactly does it mean to be DevOps?

DevOps has been around for a while -- way before there was a word for it. I think DevOps has come into its own, recently, though because platforms have become hugely more flexible while at the same time a consensus built on what it means to manage those systems. The difference, I think, is whether things are built to remain somewhat static or if change is designed for. Are development ideas like encapsulation and decoupling etc designed into the system? Smart sysadmins have been doing this stuff for a long time but now organizations are taking the approach into account all the way up and down the chain. And, yes, that means that product developers need to be fully aware of operational needs but, in my opinion, I don't think that means they build the operational tools themselves.

>your fancy 'DevOps' team just ends up being separated and isolated from the dev team you're back at square one

Demarcation of responsibility doesn't mean demarcation of information. The product development team will need to be intimately aware of what is happening in operations and vice versa. In a DevOps implementing environment it is unavoidable.

> the dev side need to understand and willing to learn about ops, it's not > rocket science

These days it's getting pretty close. I don't think it is fair to product developers to say "Listen, we like the idea of what Docker can do for us so you are going to learn it inside and out." Somewhere you have to say "Hey, we probably want to implement Docker. Ops, dig in. You know how our product is currently structured and how operations currently works with that. Try to figure out what needs to change and what doesn't. X and Y from the dev team will be made available for deeper discussions and testing as needed. When the overall gist of what has to change is known, we'll all get together, ops and produce dev, to get everyone on the same page." It's a bleeding of information, not a full on 'shake it all up' scenario.

Neither side can be a black box anymore if the current state of software development and delivery is going to be taken advantage of. But neither can everyone know and do everything or context switch as needed.

Keep in mind: I am not a DevOps theorist -- maybe I have it completely wrong according to the people that came up with it but this is my practical understanding of the movement.

</comment></comment></comment><comment><USER37> Former embedded developer, former systems developer, former language developer, former application developer, former senior systems administrator and now DBA. (30 years) Simply put, the problem IS TITLES. They cause the "not my job" problem. If you've been called, help fix the problem. If you don't understand the problem, stay with it, maybe you'll learn something. Just because your a "title" doesn't mean your s--t don't stink. Unless your are designing your CPUs, writing the languages that your write your OS and the applications that run your hardware, you are riding on the back of someone else. Do what's ask of you and ask how you can make everyone's job better. Then you'll be employed and paid well for a long time.

</comment><comment><USER38> I think the most striking point made here was the one about culture and how without everyone buying into the DevOp paradigm, its just another unused tool.

I say this because I've lived it...the last 3 (three!) companies I've contracted at were pushing dev code to live servers! Even after I setup svnserve and created the repos, no one was really interested in changing workflow. I choose svn because, lets face it, it has a much lower learning curve then git.

It wasn't until I absolutely refused to work on the live server that other the devs grudgingly started using SVN...I'm sure they are all back to FTPing to the live server now that I'm gone.

Without the proper culture from above, things just aren't going to change.

</comment><comment><USER5> I'm devops and in my opinion the title infers this; my job is to keep the communication between developers and the operations teams in sync and copacetic. Usually, Ops doesn't know dev and dev doesn't know ops so if there's nobody to translate and explain things in each others technical language things can't be done quickly and reliably. The wrong environments will be configured, things won't have backups, it will be like the wild west and things will be stressful for both sides.

My job, just like it was when I was a sysadmin, is to keep things running smoothly. To optimize both sides of the coin and to take things off their plate that I myself can deal with that might be a blocker to them finishing tasks and to us getting features out or server migrations done.

Some devs know ops and some ops know dev, those guys, more often than not I just check in with and see that things are running smoothly. For the other folk I try to create systems and workflows that get blockers out of their way.

I try to be a useful and reliable tool to both sides as much as I can be.

Hopefully the way I've been doing this for the last two years since I moved into a more Devops related role has been helpful to everyone.

<comment><USER39> Completely OT: "copacetic", new one for me - where have you come across this word; the etymology is intriguing to me.

[http://en.wiktionary.org/wiki/copacetic](http://en.wiktionary.org/wiki/copacetic)

<comment><USER5> Boy that's interesting, I've never thought about it. I'm an American who grew up in Germany but have an Italian and German family who grew up in the projects of NY (the Love Canal, Niagara Falls). My grandmother (german) and grandfather (italian) married and their families constantly fought and pretty much hated one another.

I remember them fighting (mostly arguing) and the men going "Ey ey, lets keep things copacetic." (They might have said capasetti)

I always thought it was a pretty and a smart sounding word. I guess not.

<comment><USER39> > _pretty and a smart sounding word_ //

Sounds good/smart to me! The wiktionary page mentions possible Italian-NY etymologies so you fit in there. Funnily enough I was going to try and be clever and guess you were a New Yorker [based on that] but noticed elsewhere you appear to be in TX.

Interesting, thanks for responding.

<comment><USER5> Army brat, I've been everywhere!

</comment></comment></comment></comment></comment><comment><USER40> I was recently looking for a new job, and from the job specs and interviews I have realised that 'DevOps' means very different things to many people. I am a system administrator who likes to automate things and write code, and also spent decades supporting developers and good Agile environments, etc. and production ops environments. Some companies think DevOps is a developer who knows how to deploy services on Ubuntu, and their interview tests the implementation of algorithms covered in recent CS courses. I removed any mention of DevOps from my CV, that made things less confusing for everyone.

</comment><comment><USER41> It seems OP is using the word DevOps to describe what is traditionally referred to as "special projects". Essentially, the non-technical CIO hears a new buzzword and hires a team to implement it in an ivory tower without fully partnering with existing team members. From OO to SOA to Agile to DevOps and everything in between these initiatives almost always fail. That of course doesn't mean that OO is bad, or that DevOps is bad. It is just that the "special project" methodology is terrible.

</comment><comment><USER42> To me DevOps is a cost cutting measure whereby an organization can save a few hundred thousand dollars by having one individual not only do the development but also handle the deployment and the testing.

In theory that will eliminate the need for an additional tester and a second individual to do the change control.

But those short term gains expose the organization to the massive risks that the one and only one individual will make a mistake, with no second individual available to do a double check.

The reality is people make mistakes and by eliminating people from that double checking process may well save money in the short term, but in the long run it greatly adds to the of risk failure.

While there are short term gains, the risks to the organization can be massive:

[http://www.bloomberg.com/bw/articles/2012-08-02/knight- shows...](http://www.bloomberg.com/bw/articles/2012-08-02/knight-shows-how-to- lose-440-million-in-30-minutes)

<comment><USER9> That is actually an example of the old style of IT.

The person deploying the software had no idea how it worked on an internal level.

The person who wrote the software had no idea how it was __actually __deployed in production.

They didn't have a quick rollback in place (this is the exact reason you have quick rollback ability)

The deploy was done by hand, with a user typing. That is probably the biggest risk you can have in a production system. It means that fully repeatable builds in test & pre production are impossible.

I am not saying "DevOps" would fix this, but a bit of empathy / comunications between the dev team and ops team might have averted it.

[http://en.wikipedia.org/wiki/Knight_Capital_Group#2012_stock...](http://en.wikipedia.org/wiki/Knight_Capital_Group#2012_stock_trading_disruption)

</comment></comment><comment><USER43> I have been referred to as a devops person since I have been developing distributed systems since 1998 and liked knowing and working the full stack, including hardware.

My definition of devops: small teams totally own their project, iterating on design, implementation, deployment. I have no experience with one giant devops team for an entire company.

</comment><comment><USER44> It seems that the main problem here was not DevOps but rather the culture in which he was asked to do his work. Creating a devops team whether "by fiat or by force" doesn't sound like a recipe for a good experience.

My experience is different: DevOps saves me many headaches by letting me easily deploy things for small clients. A larger company I work with uses Chef to manage their 40+ servers; the IT department doesn't touch these servers. Rather, 3 or 4 developers share in the work of writing cookbooks, adding instrumentation, deploying code and maintaining the servers. It would be handy to have a full-time guy as well (OP mentioned the amount of work needed to keep up with just your basic security patches) but we -- as developers -- love the access we have to our entire stack.

<comment><AUTHOR> I don't want to take away from your point, but you touched on security - <USER3> mentioned it because it was a constant pain point for both myself and for our teams. Like operations, it's something you can be good at on a superficial level, and do OK for most things, but really getting it and being good at it takes experience and time.

I don't think it came through in my post, but having a security expert (or any specialist) in the mix can be a huge help in making the product better - <USER3> know this from personal experience - you just have to make sure they're integrated, challenged, and respected in the group.

</comment></comment><comment><USER45> Don't know if the concept of DevOps is bs but I know that it's unfortunate if a developer never did system administration: there are many of this "git push heroku" kind of devs who pee in their pants if they have to deal with bare metal and the production servers. It's not that they wouldn't be able too handle them, it's that they are afraid because they never did and besides, good system administration knowledge leads always to better application and system design.

<comment><USER46> I blame Java much more than heroku. Corporate drone Java developers have a much greater tendency to only write code (too much code!) and not be interested in learning anything beyond the confines of their comfy auto- completing IDE. It seems to me Java developers will howl "not my job!" the loudest whenever anyone suggests that maybe they can mange their own environments.

<comment><USER47> In the enterprise Java world, the comfy auto-completing IDE is a smart strategic choice when "managing the environment" means weeks of frustration at installing, configuring and fitting together by trial and error an application server like IBM Websphere and the application. Funny tools like Maven, Subversion and certain Eclipse plugins add extra puzzles and unpredictability for the true amateur, but the normal unforeseen complications are usually enough to forfeit any hope of good automation.

</comment></comment></comment><comment><USER48> I'm a dev who learned everything by experience. I'm in my 20's and have been doing this for ~20 years, so I have a bit of experience with both the new and the old world.

My take is that the code quality of whats allowed to be in production has gotten worse, that's it. It's an effect of an abundance of RAM and virtualization. The abundance of ram lets you just trash it and do things in a horribly inefficient way. Sure the extra memory can help with time memory trade off if you have something that doesnt need to scale a great deal, but processing things inline will still be faster. Developers have forgotten how to handle streams. Usually forcing a dev to learn a highly functional language that's immutable can fix these issues (it must involve a large dataset, where you know they will tax out the memory, and then code review to help).

I mention virtualization because a common pattern I've seen is to write poor code, and just put more boxes behind the load balancer when things start failing because the technical debt is so high it's an impossible mountain to climb. This obviously isn't the right approach and will leave your devops guys worn out chasing your everyday distributed systems problems that happen because it wasn't built right for distribution and the dev has never read the fallacies of distributed computing.

And while you're fixing this technical debt a team of competent engineers builds a competing product and trumps you hard (second mover advantage).

Maybe people paid a bit more attention when things cost 10x as much as they do now and every answer (both bad and good, and you can't tell the difference) wasn't a stackoverflow search away.....

<comment><USER49> So you're in your late 20s and started working when you were in elementary school? :-)

</comment></comment><comment><USER46> Unfortunately the term DevOps has been diluted in the job market. Now most DevOps job postings are actually just plain ol' sys op roles, where "development" means writing tools for the actual developers. If you want to spend at least 50% of your time writing code then avoid any job postings that mention "ops".

</comment><comment><USER50> I'm not surprised by his experience as it mirrors a bit of mine. This was previously discussed on HN: [https://news.ycombinator.com/item?id=2674841](https://news.ycombinator.com/item?id=2674841)

Although in his post, he says:

"Another lesson learned: you can't force cultural change. It has to start from the bottom up, and it needs breathing room to grow."

I would argue that cultural change has to also start from the top. You can't change the culture if the leaders of the company don't work with you on it.

The tendency of people at the bottom is to eventually start behaving like their managers as the managers project what is acceptable and not acceptable behavior. Trying to start change from the bottom up is a hard, hard thing to do, with a low probability of success if senior management isn't on board as well.

<comment><AUTHOR> > I would argue that cultural change has to also start from the top.

This is where the "breathing room" comes in. I think that fostering an environment where people are free to organize themselves without edicts and policy produces overall better processes (and ultimately better quality).

I think it's OK for management to lay a framework, provide a particular kind of training, but it's best to provide goals that forward the company, step back and let the people closest to the work decide the best way to achieve them.

</comment></comment><comment><USER51> Whether you want to or not, it's your choice. However, the push towards DevOps as opposed to Dev is based on efficiency; it's easier to hire a developer that knows operations, instead of a developer and an operations employee. Even without DevOps, a lot of positions are Full Stack, so you need to know front and back-end development and technology. I don't think it's merely a trend, it's more or less a push towards saving money and time. If you don't want to be a full stack eng or a DevOps eng, then you're limiting yourself and you're limiting the opportunities you'll have. It sucks for those who want to limit themselves to one specific group of tasks instead of branching out, but it's just how it is.

</comment><comment><USER52> If you want to make a devops omelet at a place that has an over the wall mentality, you have to break some eggs (and walls).

I was part of a successful transition to devops from a thoroughly silo'd operation, where the boss basically gave the dev team the responsibility and authority to make it happen. He was also able to snag some of the traditional ops team and make them part of the new team. After a period of storming, the new team came up with some innovative ways to get the job done. Once the team realized that they were it in terms of getting it done, it got done. Quality and job satisfaction improved, cost was reduced.

I've also seen various unsuccessful transitions. In every case, the responsibility was divided into various silos, which sandbagged everything.

</comment><comment><USER53> DevOps may be hyped, but it's not outright bullshit. DevOps is just the realization that you would rather have a fewer people knowing everything, than many people knowing disjoint areas. The same force underpins the full stack crowd, or the notion that pizza size teams are more efficient. While this is not always possible in practice, in my experience it is better if the project is small enough that you can pull it off.

The memory bandwidth in one single person's brain is simply much higher than the bandwidth between people. To maximize performance you want to run your project on as few brains as possible.

</comment><comment><USER54> How does one reconcile DevOps with the Sarbanes-Oxley act? [http://en.wikipedia.org/wiki/Separation_of_duties](http://en.wikipedia.org/wiki/Separation_of_duties)

<comment><USER9> With difficulty. For example - you can still have an Ops team, and they have the required access. The developers access to production is done on a case by case basis, with some sort of tracking of who logged in. and why. Also, doing full pre - merge code review helps, as it is yet another set of eyes on the code that will be pushed to production...

In short - its not a "one solution fits all", and it is something that needs to be discussed with you SOX auditors, to find a working solution for your company

<comment><USER54> Thanks for the response! We keep a distinct separation of duties, but we try to keep both groups in constant contact to minimize animosity in both groups. We pick and choose some DevOps ideals to make it fit, was just curious about other people's experience.

</comment></comment></comment><comment><USER55> Having been around since the inception of this space, when things were much more tools focused, to now, when it's a lot more about "culture" (all good), I feel 95% of DevOps talks are people discussing what DevOps is. As such, it's now a metasyntactical label for a lot of things that can by good in various scenarios. I agree it is time to retire the label and instead talk about those specific things -- automation, culture, continuous improvement, etc, in nearly all instances.

</comment><comment><USER56> A senior systems administrator can and does write programs for automation, monitoring, configuration management, and all the little things that are not customer-facing applications.

I used to be able to use "senior systems administrator" as a short-hand for those skill sets, but about 2010 that stopped working.

Now I need to use "DevOps" as an imperfect substitute in the title; otherwise only junior people apply, even though the rest of the ad goes into the same depth about skills and abilities.

</comment><comment><USER57> _So that's what DevOps really is. You take a bunch of really skilled, passionate, talented people who don't have their heads shoved so far up their own asses that they can take the time to learn new things._

What you want to look out for is the formation of "walls." People have an instinct to do this. People will form cliques -- which effectively are invisible barriers to understanding and honest collaboration.

In a 5 person startup, this is easy. You have one group. Most of the critical information flows are inside this boundary, and those which aren't, the group is already intensely aware of. (Investors, customers.)

However, when headcount has started to grow, and when you are forming a separate _group_ to take on a task that requires intense collaboration, maybe you're doing the wrong thing? Maybe what you want is a separate _role_ for people who get embedded in a variety of different groups? What if DevOps people belonged to DevOps, but also, and primarily, belonged with a particular group of developers? Then, they could have firsthand experience of intense collaboration, but also meet once a week with all the other DevOps role holders and communicate to standardize and avoid duplicated effort?

A generalization of this: Make sure you're building _bridges_ and not _compartments_.

</comment><comment><USER58> Funny and, unfortunately, relevant, especially the last tweet: [https://twitter.com/devops_borat](https://twitter.com/devops_borat)

</comment><comment><USER59> DevOps is not a job. It is marketing speak.

Sure, there's this general idea that development and operations teams should work together, or of a programmer also having some experience adminning systems or vice versa. But this is as much a job description as "non-domestic car mechanic" is a job description. Generalized ideas that don't say anything but an indication of the background expected of the person.

"DevOps" or not makes no difference; _all_ corporations face the same problems with multiple segregated teams and people doing whatever they want in order to get their jobs done, as well as a sort of tunnel vision that prevents one from properly supporting your teammates or a product. To this end, there is only one thing that will make a significant difference in the work done, no matter what you call your team or position.

The best engineer in the world becomes a janitor under the wrong leadership or teamwork.

</comment><comment><USER60> I think the right thing to do is to firstly get rid of the term because it's become so meaningless and abused in so many ways. At least "cloud" has some semblance of at least meaning "whatever that we used to do in the 90s for IT is BAD" and implies great upheaval, but DevOps is a really, really weak movement in comparison because most companies that are dysfunctional try to contain whatever DevOps is into their existing (typically broken, so let's propagate that error 100x, right?) practices.

While I agree that sysadmins should be developers first it is increasingly less likely you'll find developers willing to become computer janitors and deal with the ugly realities of operations in, for example, larger companies. I wouldn't think that John Carmack ever liked having to figure out the installer scripts and keep them working across all the supported platforms through all the BS that Microsoft and different Linux distributions could throw at you, yet that's what a more "ideal" DevOps organization described by many model would have John Carmack do.

What should have happened though is that instead of hobbling the John Carmacks and dragging down their productivity, you should have fired the developers that refuse to cooperate with operations and those that keep actively putting off writing "boring" code or never documenting things that do matter for operations to figure out and learn through a failure that something broke. That kind of behavior is the developer equivalent of not being a team player at all. It's true that none of these things actually make you a better programmer in itself, but these things are what contribute to making you more PROFESSIONAL instead of a cowboy renegade programmer that doesn't care if nobody else can use his code because "clearly, if you can't figure it out quickly you don't deserve to use it" (not an exaggeration at all I've heard).

Having been in both development and operations in rather large (and small!) companies now, I'd far, far, far rather stay as a hermit-crab developer than deal with the constant dysfunctions of enterprise Faustian nightmares that are required for you to deal with as an operations engineer. You can generally ignore a lot of the noise in a super-siloed off R&D organization, for example, but you cannot ignore your pager going off at 2 am because a random server crashed causing someone to get very, very angry and demand immediate resolution when it is your JOB to keep those things going. Hardly going to write anything really meaningful with that ruining your work week pretty much every week.

</comment><comment><USER61> Is it just me or are development practices (sem ver, git flow, test coverage, in-house code guidelines, even vcs and CI) the kinds of things that go out the window when a DevOps team forms, because they're "too slow"? For example, who has time to ensure 100% code coverage for your script that's going to fix the problem with your load balancer?

The exact same thing I'm noticing is happening with the "automation" teams that are cropping up. It's like folks are discovering ways of getting around process, forgetting completely why the process exists in the first place.

<comment><USER62> One thing I generally insist on, is that the DevOps Engineers are held to the same standard as the Dev's when it comes to version control, testing and documentation. After all - that goes hand in hand with the 'Dev' part of the title.

</comment></comment><comment><USER63> Devops is a professional movement to codify knowledge about how web companies operate at scale and speed. It gets misinterpreted sometimes (more lately as it becomes a fad). Doesn't mean its bullshit. Same problems with Agile, Lean, Six Sigma, or any other codification of how humans could or should work together to deliver a product.

Many of the lessons learned here aren't exactly universal, for example some of the better Devops cultures (e.g Google) do have separate dev & ops teams, they just have good collaboration.

</comment><comment><USER64> I think DevOps is a bit of a fad anyway, because a huge chunk of the problems people are solving will soon be solved by off-the-shelf standard cloud solutions. It makes no sense for everyone to be writing their own deployment/configuration Chef and Docker setups when they can just use increasingly powerful and flexible PaaS options like AppEngine/Heroku.

</comment><comment><USER65> This piece is so confounding about what Devops is and isn't, so much that I'm ready to just flip the bozo bit on anyone who uses the term credulously. This is silly.

<comment><AUTHOR> Now you know how I feel.

</comment></comment><comment><USER66> tl;dr because waking up in the middle of the night to debug someone else's app really, really sucks.

</comment><comment><USER67> A smart, meticulous, better than other people person like myself can't get past the hubris, sorry.

</comment><comment><USER7> why devops isn't bullshit: [http://blog.valbonne-consulting.com/2015/03/10/is- devops-bul...](http://blog.valbonne-consulting.com/2015/03/10/is-devops- bullshit/)

</comment><comment><USER68> Once again, we have the stylish new white background with barely legible text design pattern showing on HN.

<comment><USER69> Agreed, the font is very light weight. The way it renders on my screen (Macbook Air) gives me a headache.

<comment> agarcia-deniz I'm glad it's not just me. looks like he changed it to something else

</comment></comment></comment><comment><USER70> It seems like a mere attempt to adapt labor-division best practices from assembly plant industry. More managers, bigger budgets, easy staff rotation - that kind of crap. Also a fresh new meme to ride on. Nothing special.

</comment><comment><USER71> I will sum this up:

> We had edicts to make things happen, under the assumption that if we built > it, the developers would embrace it.

Followed by:

> What matters is good people working together without artificial boundaries.

Former will never produce latter. Always work with engineering before building anything that impacts their day to day.</comment>


How Hampton Creek Sold Silicon Valley on a Fake-Mayo Miracle - <AUTHOR> https://www.bloomberg.com/features/2016-hampton-creek-just-mayo/ <comment><USER2> Good reporting from Bloomberg as always. I thought just mayo was okay when I first tried it (didn't know it was a startup then, had I, I probably would have picked a different one). It's still in my fridge, unfinished. Doesn't seem like a product that could give a company a billion dollar value.

Hopefully if anything happens to the company they will open source whatever code they have for machine learning about plants. Maybe somebody else can glean something from it.

<comment> xkcd-sucks >didn't know it was a startup then, had I, I probably would have picked a different one

It's an okay way to get stuff at less than cost though, if it's backed by VC money and focused on growth</comment></comment>


First Detection of the 21cm Cosmic Dawn Signal - <AUTHOR> https://astrobites.org/2018/03/14/first-detection-of-the-21cm-cosmic-dawn-signal/ <comment><USER2> This is incredibly cool. The signal is hard to detect because it's quite faint and there are tons of other signals superimposed on it: the galactic synchrotron, other astronomical sources, and terrestrial radio (FM, for example). And the neutral hydrogen involved can both emit and absorb 21cm light. Getting it right is _hard_ , but various groups are working on it.

Once we can not just detect the signal but measure its spatial and frequency variation, we'll get a very nice map of the earlier universe. In particular, the 21cm line is very narrow, so its power spectrum as observed from Earth gives the strength of the signal as a function of redshift, which is strongly related to distance. If we can get some decent spatial resolution, this will give us a 3D map of the density of neutral hydrogen on the early universe.

This will give great data for cosmological calculations. Most useful cosmological observations right now are either 2-dimensional (e.g. the cosmic microwave background, which we can resolve angularly with great detail but represents a very narrow slice of time) or barely 3-dimensional (supernova observations, for example, which let us map a much smaller range of times than we can potentially map with 21cm observation).

(Part of my thesis was on an approach to detecting the 21cm signal and its spatial variations.)

Followup: A friend who works on HERA, which is also looking for the 21cm signal, forwarded this discussion: [https://twitter.com/UCBProf/status/969071237405097985](https://twitter.com/UCBProf/status/969071237405097985)

<comment><USER3> > _the galactic synchrotron_

"The plane of the Milky Way is dominated by diffuse radio emission with a brightness temperature of thousands of Kelvin at low radio frequencies (Zheng et al. 2016). This emission originates from relativistic electrons interacting with the Galactic magnetic field."

[https://uhra.herts.ac.uk/bitstream/handle/2299/17665/stw2959...](https://uhra.herts.ac.uk/bitstream/handle/2299/17665/stw2959.pdf?sequence=2)

<comment><USER4> Question: Why the galactic synchrotron and not, say, the solar synchrotron? I'm assuming the latter exists but is negligible for some reason? Why is that?

<comment><USER5> Apparently the particles need to be relativistic, maybe the Sun doesn't generate enough acceleration compared to the central galactic supermassive black hole?

</comment></comment></comment></comment><comment><USER6> 21cm was initially misleading; that's the origination of the hydrogen line at 1420MHz; by the time it reaches earth it is doppler shifted down (redshift) to 78MHz!

I worked as an antenna engineer on the VLA's low-band Epoch of Reionization expansion project in 2014[1], which focused on 74MHz signals. They've been looking at this frequency since 1999 [2] but who knew they were 4MHz low! (I doubt that they just didn't look there, likely some other effects or local RFI problems, as Australia is a lot more remote than New Mexico.)

[1] [http://lwa.phys.unm.edu/users14/Ellingson_MJP.pdf](http://lwa.phys.unm.edu/users14/Ellingson_MJP.pdf) [2] [https://www.nrao.edu/pr/1999/74mhz/](https://www.nrao.edu/pr/1999/74mhz/)

</comment><comment><USER7> Quasi-related fact:

Radio frequencies with a wavelength of 21cm are one of SETI's favorite places to look for artificial signals. Since it originates from atomic hydrogen (of which there is a _lot_ ), it's one of the notes that the universe likes to hum to itself---and radio-using species everywhere would probably figure that out.

<comment><USER8> So, do _we_ deliberately transmit at that wavelength, with the intention of attracting the attention of ETIs?

<comment><USER9> It's certainly one of the better ideas for that purpose. I like to imagine, though, that the sufficiently advanced aliens, upon receiving the signal, would say "huh, there's this weird low energy 1420Mhz emission coming from Sol. Guess we'll file it next to the other million aberrant emissions in the Local Group we can't explain."

</comment></comment></comment><comment><USER4> OK, I don't really understand this. What exactly is this cosmic dawn signal that's distinct from all the other things on 21cm?

<comment><USER10> Apologies if this is oversimplified.

In the (time shortly after the) beginning the universe was formless and void, and all that existed was hydrogen and hydrogen was all that existed. Over time the hydrogen clumped together through various forces such as gravity. Eventually enough hydrogen clumped together that the force of gravity was sufficient to trigger nuclear fusion. And then there was light.

Hydrogen can absorb or (suitably excited) emit light at 21cm wavelength specifically, better than all other wavelengths. So from the background smorgasbord of frequencies emitted by the extremely hot hydrogen of the first stars ("First Light") the cold hydrogen would have absorbed some as heat, and absorbed more at 21cm as excitation energy.

So assuming a relatively linear distribution of wavelengths in First Light (you could call it "white" light) there will be a portion where photons at 21cm were absorbed by hydrogen.

So the Cosmic Dawn signal is distinct because of what it is missing.

<comment><USER11> > Hydrogen can absorb or (suitably excited) emit light at 21cm wavelength > specifically, better than all other wavelengths.

Based on the article, I don't think this is right. [http://astronomy.swin.edu.au/cosmos/S/Spin- flip+Transition](http://astronomy.swin.edu.au/cosmos/S/Spin-flip+Transition), linked, describes the 21cm emission as occurring once every 10 million years for a single atom.</comment></comment></comment>


How an Atari Chip Set Off a War Among Neuroscientists - <AUTHOR> https://www.wired.com/2017/03/atari-chip-set-off-bitter-war-among-neuroscientists/ <comment><USER2> Strange to call the 6502 as "an Atari Chip" (yes, I know that was the Wired title). Yes, several Atari systems, including the 2600 and 400/800 series used the CPU, but they didn't design it and many other companies also used it. The Commodore 64, Apple II, and BBC Micro also were 6502-based.

</comment><comment><USER3> a war, really?</comment>


Want more Angel investing in the UK? Then let's talk about returns - <AUTHOR> http://eu.techcrunch.com/2010/08/05/want-more-angel-investing-in-the-uk-then-let%e2%80%99s-talk-about-returns/ <comment><USER2> Dup: <http://news.ycombinator.com/item?id=1577749></comment>


Moonpig: a billing system that doesn't suck - <AUTHOR> http://blog.plover.com/prog/Moonpig.html <comment><USER2> > No fucking floats

<rant> Every time I see floats being used for stuff like currency, which is still more often than not, I'm reminded how very immature and unprofessional the business of programming still is. This situation has barely improved in the 25+ years I've been in IT.

For fuck sake, we're not talking "advanced" stuff like architecture, algorithms, unit testing, SOLID, or whatever, but basic use of simple tools that's equivalent to understanding that you don't use a hammer to drive in a screw.

I can't imagine any other profession where basic stuff is executed so cluelessly unless it's a deliberate scam.

Right now, as we speak, clients and/or employers are paying many thousands of dollars/euros/whatever to have brand new software build by programmers who will use floats for what are supposed to be exact amounts of money the core business of their employer/client depends on.

It's a pathetic state of affairs which makes the phrase "software is eating the world" an utterly terrifying idea.

And now there's a movement that wants to teach everyone "how to code".

The apocalypse will be caused by a rounding error. </rant>

<comment><USER3> So how does the latest darling of the webapp world, nodejs, handle this? In javascript, the only numeric type is float.

<comment><USER4> The same way you do it in Perl: you store rounded millicents. If there's never any fraction in your float, your math will never have floating point issues, and your Javascript VM will use integers internally.

</comment></comment></comment><comment><USER5> Although I agree with most of the article, I think the moment the words "millicents" and "billing system" are used in one sentence you should stop, drop, and ask yourself what the heck you're doing.

Just save billing stuff in cents and do internal billing math using arbitrary precision integer math and round to %0.2f at the end. Nobody cares about mistakes that involve fractions of a cent, or whether their subscription lasts 1 year or 365 days or 52 weeks of 7 days. Just pro-rate in the easiest way possible and round in favor of the customer. You just don't need any of this fraction-of-a-cent BS.

If your billing math is easy you can even explain how it works in the FAQ so customers won't feel cheated. If your billing is complex and uses millicents in an misguided attempt to "do the right thing" then you can't explain to your customers how it works and why it's fair. That's no good from the customer's point of view.

Billing systems are easy to over-engineer and in my experience you just want a system that's straightforward and correct. That way you can focus your energy on more important stuff.

<comment><USER6> He gave good reasons why they used millicents, one of the best reasons was that it prevents things like a customer owing $0.006 and therefore getting a "past due" bill for $0.00. Another was that it prevents real errors from hiding as possible round-off errors. I found the reasoning convincing myself, and yes, I have worked in the financial industry.

<comment><USER5> I agree that using regular floats for money is insanity. Aside from that I'm not convinced at all, because the situation never arises where you want to charge people 0.01 cents or 17c for that matter. Who in their right mind is going to generate an invoice for 17 cents?

If people have a small amount of credit just give them an extra day of service. If they have a small negative credit either ignore it or subtract one day the next time they renew.

If there is a case for using milicents I sure haven't seen it.

<comment><USER7> As I understood it, the basis for their system was that each customer's account contains the actual current balance (remaining value) at any point (any given day). If you charge $10/year for a service that's 2.739726027 cents per day. You can't have a system like that and round to pennies without some serious error at the end of a year.

I'm not sure I understand the value of a system like that though. In the systems I've used and built, most customers see their service as an annual thing that renews on a particular date every year, for which they pay an annual fee. Doing it as a daily fee simplifies the special cases like converting between plans but makes it harder to deal with "your annual plan always renews on this date".

<comment><USER6> The way I understood it is they chose the resolution of millicents because it was precise enough to allow an annual plan that was never converted to have this behaviour, yet be cleanly convertible.

</comment></comment></comment></comment></comment><comment><USER8> The naming of this is unfortunate [1].

[1]: [https://moonpig.com](https://moonpig.com)

<comment><USER9> Quite! I and any others from the UK are likely to assume it's something to do with an annoying virtual/printing greetings card company.

<comment><USER10> Further to which, I suspect this might run into trademark difficulties.

<comment><USER11> There's no likelihood of consumer confusion between a billing software package and a greeting card store. Trademarks are not total ownership of words.

<comment><USER8> Those two sentences are completely unrelated. The first sentence is false if the two companies have the same name. The second is true.

<comment><USER11> First, the companies don't have the same name. It's the name of a software package, not the company that created it.

Second, that's not relevant, but is relevant to the rest of my comment. Trademark law does not bar two companies from having the same name. There are _tens of thousands_ of companies with the same name. Most words have hundreds of separate listings in the trademark registry. Ever heard of Delta the airline, Delta the faucet company, Acme the laboratory, Acme the furniture company, Acme the grocery store chain, Apple the computer company or Apple the record label?

Trademarks are limited both regionally and by the categories of goods and services the marks are registered under. If there is no likelihood of consumer confusion, there is not going to be infringement. Moonpig's trademark is limited exclusively to "printed matter, namely, books in the field of humor, stationery, greeting cards, and calendars".

</comment></comment></comment></comment></comment></comment><comment><USER3> _Times and time zones suck ... Floating-point arithmetic sucks ... Rounding errors suck ... Relational databases suck_

Guess what, any decent relational database will have a MONEY or at least a fixed precision DECIMAL type, as well as DATETIME and all the ancillary functions for computing intervals and adding and subtracting time. Half of your problems were because you weren't using a data store that properly represented your data.

</comment><comment><USER12> The first time that I heard an annoying advert for the card company "moonpig.com" I pretty much heard it as "all_the_good_domain_names_are_taken.com" [http://www.youtube.com/watch?v=MEBy67ZUrxQ](http://www.youtube.com/watch?v=MEBy67ZUrxQ)

But apparently "moonpig" is not just a totally random name, if two different groups can come up with it.

<comment><USER13> moonpig.com is an interesting startup and exit story. Moonpig was his nickname at school. He was a rotund child and not terribly popular. he had the last laugh though exiting for several hundred million.

<comment><USER14> Well £120m. Still pretty good for selling a few greetings cards.

[http://www.bbc.co.uk/news/business-14275632](http://www.bbc.co.uk/news/business-14275632)

</comment></comment></comment><comment><USER15> A relational database would have been a much better fit for this system.

The author initially states that all relational databases are good for is speed but then goes on to highlight flaws in their object store that could all have been mitigated by using an RDS:

* schema changes without needing to write programs to update all your data

* data aggregation (and in fact any sort of adhoc reporting)

* data storage independence.

There's also no mention of data integrity but this is a big risk as soon as the original authors are no longer involved.

Object oriented data stores are hierarchical/network databases. Relational databases were introduced to replace these years ago and for good reason.

<comment><USER16> But... if your data is hierarchical in nature, then trying stuff it into a relational database results in a giant clusterfuck.

Just use the right tool for the job.

<comment><USER15> How so? Modern RDBMS' are more than capable of manipulating hierarchical data.

</comment></comment></comment><comment><USER17> I'm not sure I can take seriously anyone who thinks an ACID-compliant RDBMS sucks for ledger accounting. Is it the RDBMS' fault that you don't know how to do extremely basic transaction recording? This isn't reinventing the wheel here, you don't have to design your own schema, there are plenty of examples readily available on the 'net.

</comment><comment><USER18> "Happily, Moonpig did not have to deal with multiple currencies. That would have added tremendous complexity to the financial calculations, and I am not confident that Rik and I could have gotten it right in the time available."

Yeah, so, that tells me that sadly, regardless of the rest, it sucks (sorry). Not supporting multiple currencies, as he says, _does_ vastly simplify things, but is also a massive feature-gap, as any merchant of scale _will_ deal in multiple currencies. Now try doing it _with_ multiple currencies, and still avoiding floating point arithmetic. Oh, and also ensure that it'll deal with charging sales tax/VAT on transactions of £0.01 correctly.

<comment><USER19> The crazy thing about software is that when business requirements change, you can change it. If they don't need to support multiple currencies today, it's silly for them to put in the effort now.

<comment><USER18> Very true, however design decisions made at an early stage can make changes of that ilk challenging, and even nigh on impossible without significant rewrite, down the road.

</comment></comment></comment><comment><USER20> It's interesting to see the differences in design decisions they used vs. the "ledger" program that I've used for a while ([http://ledger- cli.org](http://ledger-cli.org)).

Specifically, that ledger internally uses an arbitrary precision library to store data, then only cuts down or rounds numbers at the display level, and the use of libraries and a database vs. a file format and highly optimized code.

</comment><comment><USER21> Here's the video of the Pittsburgh Perl Workshop talk this post was _mostly a rehash of_ \- [http://www.youtube.com/watch?v=lp2z_ZbLE_I](http://www.youtube.com/watch?v=lp2z_ZbLE_I)

<comment><USER22> Ugh, he mentions in the post that it was a write-up of the talk.

<comment><USER21> Yes but the link to the Youtube video isn't provided in his post :)

</comment></comment></comment><comment><USER23> Due to the formatting and the use of Perl I had to check the date of the article as I thought it perhaps was a 10 year old article. But it was from last week.

But that is current me being a slight code snob as I did use Perl as my prime language for a few years but that was 13 years ago.

As someone who have worked with many payment and billing systems I can see some of the pain addressed. But also reinventing the flat wheel is something I try to avoid and keeping things simple so for example these days I use BigDecimal, BigInteger datatypes and similar in more modern languages.

Ps. as someone who just ordered cards from moonpig.com, the name was initially confusing.

<comment><USER14> Yeah it seems kind of an odd choice to write the thing in Perl. I guess they have some other Perl stuff they want to link it with perhaps?

<comment><USER24> Perl has the most libraries and most active extension system of any programming language available. It runs the entire Internet.

</comment></comment></comment><comment><USER25> More a discussion about why not to use PERL than anything else.

Also, hire a branding expert - "moonpig" is awful in every way possible.</comment>