davidkellis

or https://traefik.io/

This seems to be a verbose restatement of the Golden Rule - https://en.wikipedia.org/wiki/Golden_Rule - that one is taught as a child.

If the domain is a mainstream tech/political/general-interest/news organization, then I ignore it.

> You push data consistency concerns out of the database and between service boundaries.

Sing that from the rooftops. That is exactly my observation as well. All the vanilla "track some resource"-style webapps I've worked on were never designed to cope with a consistency boundary that spans across service boundaries. Turning a monolith into distributed services is hard for that reason - you have to redesign your data access to ensure that consistency boundaries don't span across multiple services. If you don't do that, then you have to learn to cope with eventual consistency; in my experience, most people just don't think that way. I know I have trouble with it. Surely I'm not the only one.

I think that's where side projects come into play. I'm working on a language project on the side because, just as you mentioned, work consists mostly of CRUD APIs around tracking business resources.

I had just switched all my domains over to porkbun for this very reason - whois guard wasn't free at namecheap. I think I'll just leave the domains I moved there, and then continue with namecheap going forward. Now I view them as essentially equivalent plus or minus a few pennies per year.

I've been bitten by this before as a customer. I tried signing up for FastMail and was unable to create an account because their signup page required I supply a non-voip phone number. My phone carrier - Republic Wireless - is a voip-only carrier. Google Voice is also voip-only. At least, that's how their phone number check reported my phone numbers.

Sure, access to the source is acceptable if they're offering to buy you out.

This strikes a chord with me, but I'm coming at it from a different angle.

Does anyone else encounter very large diffs as standard operating procedure in golang codebases? Here I'm considering "very large" to mean 500+ lines changed - however github computes lines changed.

I mean, I'm looking at this from the perspective of someone who contributes primarily to Ruby codebases. It's understandable that there would be a difference when comparing ruby/go, but the magnitude of the difference is what I'm getting at.

The difference I'm observing in the average size of a PR in a plain old Rails codebase compared to the average size of a PR in a golang codebase is dramatic - roughly an order of magnitude. In some cases it's even more extreme.

Is that anyone else's observation, or am I just doing it wrong?

What's the consensus about doing this in Texas? Anyone been through it that can advise?

There's nothing new here. It's been like this for a long time. One person's despot is another's savior, and vice versa.

Timing is suspect. We've known this for a long time.

Lisp, or any prefix or postfix language, is relatively easy to parse and execute (in the case of an interpreter) or translate (in the case of a compiler/translator) because its syntactic structure mirrors the abstract syntax tree (AST) that the semantic analysis phase (i.e. the last of the 3 phases identified in the post) will traverse as it either executes (interpreter) or translates (compiler). In other words, the parse tree is nearly identical to the AST. That isn't true of Algol-like languages, and so the syntactic analysis and semantic analysis phases of a compiler/translator of Algol-like languages is more complex. That's why Lisp, or really any prefix or postfix language, is a good first language to implement, as opposed to something like C.

Open source really is irrelevant. We don't know what code they deployed - it could be an open source project (we hope so), it might be an open source project with some minor changes - an NSA-approved backdoor for example, etc. We don't have any guarantee, so far as I'm aware, of what they're running, much less that it does what it claims to do.

My takeaway is that development managers shouldn't put a bunch of lead developers together on a project, unless the project is big enough that each leader could own an independent piece. Otherwise, toes get stepped on, folks start bickering, and progress grinds to a halt.

But what does it cost?

Rackspace | San Antonio, TX | Full-time Ruby/Go (Golang) Developer

I'm a dev on one of the automation teams at Rackspace, and we're looking for a Ruby/Go developer to add to our team.

Our team owns a suite of monolithic Rails apps, and we're replacing some of them with Golang services. We primarily work on backend logic, though we, in conjunction with a sister team, maintain the GUIs in the Rails apps. All the Golang work is backend logic only.

The open position is posted in a couple of places:

1. Racker Talent: https://uscareers-rackspace.icims.com/jobs/15798/software-de...

2. LinkedIn: https://www.linkedin.com/jobs2/view/81849144?trk=vsrp_jobs_r...

I used Scalatra on one other project, and I found it to be difficult to deploy. Whether it's true or not, my impression is that Spark is a little simpler to use and deploy than Scalatra. Scalatra is my second choice though.

Backend:

Scala

Spark - http://sparkjava.com

ScalikeJDBC - http://scalikejdbc.org

Postgres

Coming from Rubyland (and AR specifically), I despise writing a bunch of dao/repo code, so I've resorted to codegen-ing my daos/repos.

Frontend:

Aurelia - http://aurelia.io

cgh, I've hit the reply limit, but I wanted to ask how you'd implement the cascade deletes thing over services? Would the People service have to emit events describing that a person was deleted that the Address and Billing services would be expected to subscribe to in order to handle that the person was deleted?

But what about the situation where you have an entity service that owns the data for one piece of the domain, for example a People service, and then other services, like the Address service and the Billing service, reference a particular person. In that scenario, I can imagine the Address service and the Billing service would have a foreign key referencing a person in the People service. Then, what happens if the Person gets deleted? In that case, we've got a consistency problem, even though each service owned its data.

Is the best practice to not use entity services?

The consistency problem is an open question in my mind. I definitely don't like the idea of having some data synchronization tool to fix the inconsistent data across services problem. I wonder what the best practice is for maintaining data consistency across services.

Does anyone know?

Ease of use. It should be easy to use. Someone else commented that simple is what makes an API good. To the extent that a simple API is easy to use, I agree.

I think an API is no different from any other software product. People like software that is easy to use. I think an API should be easy to use too. To me, that's what makes an API good.

Evidence-Based Technical Analysis - David Aronson ; Chapters 4 and 5 give a very accessible explanation of statistical inference through the use of sampling distributions. It's an excellent book.

I think you hit the nail on the head about the space industry being risk averse. I think that guides a lot of their decision making.

I took a compiler class that was taught by the inventor (Dr. Daniel Cooke) of another functional language, SequenceL (see http://en.wikipedia.org/wiki/SequenceL). Cooke had funding from NASA to develop SequenceL because evidently NASA was/is very interested in program correctness (it's hard to guarantee correctness of a C++ program) and a simplified programming model.

The way Cooke explained it in class, SequenceL was born out of a desire for a simpler programming language (he believed that modern programming languages are too complex - so many require extra tooling to be productive) and a desire to make the implementation of a program as close as possible to the definition of the problem. He reasoned that if you could make an executable specification (i.e. the definition of the problem was executable), then all the mistakes that implementers make while implementing a program based on the problem specification/requirements would go away. In other words, since the definition of the problem would be the implementation, zero implementation mistakes would be made.

Interestingly enough, the first SequenceL interpreter and compiler was written in Haskell.

I don't see the privacy concern. Is the fear that Condi is going to persuade Dropbox leadership to open the doors to govt. snooping?

Why is this on HN? This is just a political powder keg. Anyone who agrees with the article will upvote it and any comment supporting it. Anyone who disagrees with the article will downvote it and any comment opposing it.

The only "benefit" to this post is that the publicity given to the grievance (whether real or imagined) will sway Dropbox leadership to drop Condi. Whether that's a good thing or not for Dropbox as a business is not even considered. The content of the article has no real benefit to anyone.

Jewelry.

The performance graphs look promising, but the second graph in the Parallelism section seems suspect to me. Why didn't they plot the graph out to 8 threads, like they did with the first graph?

Edit: I don't mean to sound snarky, I'm definitely impressed.