dkubb

I would recommend SQL and Relational Theory by CJ Date.

It completely changed how I use SQL. Before reading it, I had about a decade of experience with SQL. I didn't really understand the theory underneath. I also didn't understand how to write SQL in a way that adheres to the theory.

You can think of this book as being the closest we have to "SQL: The Good Parts".

This also means that if you want to break into twitter all you need to do is break into slack.

And yet, effective marketing is less about the quantifiable and more about the subjective feelings that your product will ultimately provide.

I think he means Mainstream Media. It's the first time I've seen that abbreviation too.

I love Postgres, but the only thing I find myself wishing for was better Unicode support in the regex engine. I like to add strong database constraints, and sometimes lean on the regexp engine but I find it's missing a lot of features available in other regexp engines. PCRE compatibility would be ideal, but even just support for the Unicode \p classes would be a big step up.

I don't recognize your handle, but nice that you remember DataMapper!

I'm doing really well, although I did kind of fall off OSS work as I got busier with kids and family stuff. I still hack on lots of different things, but nothing that I've been able to open source. I've been busy learning Haskell these days, although I tend to write Ruby for work.

For me, it's always been select/reject/detect. Even though I know about find_all, it always seemed like the odd one out.

You could make the comment about the change, then create a fixup commit and allow the original author to decide to merge it or not.

If I might make a suggestion, I'd recommend doing some kind of tracing when you run the tests so you can have a mapping of what parts of your code are exercised by which gems/tests. Then when you make changes to your code you can run the tests that relate to that part of the system first, thus giving you more confidence that your change didn't cause a regression. This should be much more efficient than simply doing a full gem run (although I'd recommend that too, since it could uncover hidden dependencies).

There is rubyspec, but it doesn't cover all possible paths, just the ones that the developers deemed important enough to test.

What I am curious to know is _what_ does ruby use besides rubyspec? Do they run tests against the top 100, 1000, etc rubygems before releasing? I know other communities like Rust (and even Perl) do this kind of regression testing. While this won't catch all possible regressions it seems like a reasonable starting point to uncover issues before a release.

It's a common misconception that Haskell is slow to compile but not really true, see for example: http://www.shimweasel.com/2016/10/24/fast-tests-and-static-l...

This is correct. It's probably hard to measure a person's total contribution to DataMapper because the gems are spread out across 20 to 30 repositories, not just dm-core.

I did maintain DM for a few years, but burnt out as there wasn't enough time to keep up with the community demands and work a full time job. There were a couple of years I effectively worked 40-60 hours a week on DM and only 5-10 on work; this wasn't tenable long term and burned me out.

The small dev team, of which solnic was a core member, are an amazing group and there's no way I could've maintained DM for even a fraction of the time I did without their support.

(Serious question) Isn't it risky to rely on any Google product as a foundation for your business?

They've shut down more popular services that people depend on than Google Cloud. They tend to enter a market, undercut all the competitors, and then once they are dominant in the niche they terminate or change the service in a way that makes it not fulfill the original promise.

My main feature request would be a way to enforce a PR must be a fast-forward merge.

I tend to have a small set of words I prefix each git commit summary with (Add, Remove, Fix, etc). If I could verify summaries match that pattern that would be awesome.

Also, if it is possible to enforce the guidelines specified in http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa... I'd be so happy.

I saw this comment and then started looking for a link to a second page. It turns out I was able to "swipe up" on my magic mouse to scroll down to the second page.

I'd strongly recommend that the developer stop hiding the scrollbar.

I wonder if they considered breaking the app up into smaller parts that can be sold to different markets:

  * API that accepts the scanned images, parses and returns the receipt data.
  * API (that does the above and) stores the data to allow later exporting of
    receipt data in Quickbooks, Excel, and other formats.
  * IOS and Android Libraries that integrate with the API.
  * Birdly app build on top of the library and API.

Birdly could be used as an end-user application, but also as a showcase for the API usage. Other application developers could license the libraries and API from your service; sure it creates competition, but you'd be getting a slice from a larger pie.

Also if there was a solo API plan, I would probably consider something like this for some personal expense tracking software I've been thinking about writing for myself.

I feel like many of the general chroot principles in this article can be applied to containers.

> Perhaps containers will be forgotten too.

OT but my guess is that we'll move towards deploying applications as part of a unikernel instead of running them inside operating systems designed for multi-user usage. Multiple applications may be run on physical hardware using some sort of hypervisor, but I don't see the point in having all this overhead just to wall your application off of with Docker.

With that said, I do use Docker, but only because it's a step up from what I've previously used. Long term I'm looking towards deploying my applications with a unikernel.

For NixOS it looks like there was some work on reproducible builds, but it seems to have stalled: https://github.com/NixOS/nixpkgs/pull/2281

Do you have any experience with S6? Do you know how it compares to runit?

How does this differ from golang-builder? [1]

[1] https://github.com/CenturyLinkLabs/golang-builder

I'd also recommend introducing mutation testing in addition to fuzz testing.

There is some overlap between the two techniques, but they approach the problem from completely different directions. Fuzz testing randomly generates inputs and uses that to find bugs where the input is improperly handled. Mutation testing randomly changes the code to make sure the tests themselves cover all the code that is written.

A good approach is to use mutation testing to make sure the existing code is fully covered by the tests. Then use fuzz testing to identify new failing test cases that need to be written. Once the implementation handles the new test cases, mutation test that code to make sure there aren't any untested code paths.

I used this same approach on an Relational Algebra + SQL generator lib I wrote a while ago and the result was something that was very stable -- the only bugs were due to flaws in my own understanding of the specification, not bugs in the implementation.

Yeah, obviously we do that (well maybe not so obvious to some, but I never push unless the tests pass). We sometimes perform lots of other things like static analysis that get in the way of a rapid feedback loop. We also run mutation testing, which can sometimes take several hours for the whole codebase -- although we don't have this run on every commit, just ones that we merge into a specific branch.

The problem I have with non-linear commit history is that I find it impossible to keep all the paths straight in my head when I am trying to understand a series of changes. Maybe you can do that, and I think that's awesome, but I like to see a master branch and then smaller feature branches that break off and then combine back with master.

Another nice side benefit is that you are able to use git bisect to find bugs more easily. If some of the commits fail the build then it becomes difficult to separate commits that actually introduce a bug from those that are just incomplete.

The team I work with has recently started making sure every commit passes the build and it's had some fantastic results in our productivity. We know every individual commit passes on it's own. If we cherry-pick something in that it's most likely going to pass; so if it fails then usually the problem is in that specific commit, not one made days or weeks ago.

Did you mean to say "semantic error" instead of "syntax error"?

I believe that ugly code is usually buggy code. If someone didn't take the time to deal with trivial issues like formatting then it makes me wonder if they spent time thinking hard about the actual problem they were trying to solve.

I usually explicitly do code reviews in 2 passes. I look for low level problems first, and also try to identify ways that they can be tested using tools so that next time they are caught before the code is sent for review. My second pass looks at higher level problems with the overall design and checks the functionality to make sure it matches the objectives.

Would it be possible to add RSS feeds for each category page? I currently read HN via an RSS reader and filter out any articles with less than 10 points. I would much rather filter out categories I don't care too much about.

Is it possible to prove most of the system so that the remaining unprovable parts are minimized?

You could side-step leap second issues by using a TAI based timestamp.

Thank you for mentioning this. What I don't understand is that no one is talking about the responsibility of the programs reading the user input. They have a responsibility to validate anything they receive using a whitelisting approach (i.e. denying anything that doesn't match expected patterns).

If a program simply slurps in user input without doing any basic validation according to published RFCs then there's a bug in that program.