HN Theater @HNTheaterMonth

Rich Hickey - "simple made easy" https://youtu.be/rI8tNMsozo0

Rob Pike - "concurrency is not parallelism" https://youtu.be/cN_DpYBzKso

Uncle Bob Martin - "future of programming" https://youtu.be/ecIWPzGEbFc

Martin Kleppmann - "transactions: myths, surprises and opportunities" https://youtu.be/5ZjhNTM8XU8

Simon Brown - "software architecture vs code" https://youtu.be/GAFZcYlO5S0

⬐ sparq_beam

That transaction talk is really good, thank you. I can now finally name the effect that I had noticed but had trouble explaining and referring to, write skews.

It's interesting that he doesn't mention phantom reads as the difference between repeatable read/snapshot isolation, and serializable, which is what other sources tend to do.

Snapshot isolation always seemed to me like cheating the intended meaning of repeatable read, insofar as some databases refer to their snapshot isolation level as repeatable read.

That is, in the strictest sense, if you read a row twice, you get the same value with snapshot isolation, but you don't actually know that the value will be the same when you commit, which as I understand is a case of a write skew.

In fact, if one thinks of the definition of these levels in terms of locking semantics, one would expect a repeatable read to have the same meaning as obtaining a read lock on the row you read, which I understand would prevent at least some types of write skew, since no modification would be possible on that row, because it would need a write lock. There could still be hazards related to phantom reads (and possibly other effects), such as making a decision based on a computed aggregate that can change if new rows are inserted. Still, this meaning of repeatable reads would already provide a useful isolation level for various cases, except that it doesn't work with snapshot isolation.

I have a suspicion that applications out there made incorrect assumptions as to the actual isolation provided by the DB they use.

https://www.youtube.com/watch?v=GAFZcYlO5S0

https://www.youtube.com/watch?v=iukBMY4apvI (javascript module workflow that helped me (frontend dev) to transition to modules)

help?

⬐ porker

Watching Simon Brown now & will look at his book too, thanks.

To take the current project, I have a CMS, Salesforce and ExactTarget. I'm writing the glue to automate taking new content from the CMS, finding SF users with the right permissions to see it, and emailing it to them via ExactTarget.

All good & working until... do I model it as 3 objects? Which object is responsible for creating the DataTable at ExactTarget (populated with SF data)? How is data going to be passed around cleanly between my representations of all 3 services? Or should I represent the system more abstractly as EmailToSend, EmailContent and use all three services within these classes?

⬐ rmetzler

I think, you overthink it.

Make 3 scripts

1. get-content

2. get-emails

3. send-content-to-emails

call this in a cronjob. Have logs.

The second day you will realize, you'll send the same content to the same people, so you'll need to add a filter. A simple file or database-based filter will be sufficient. You should be able to generate this filter from the logs.

Add this steps before sending emails:

* filter-emails

* filter-content

* generate-email-to-content-relation

⬐ gdy

In my opinion it's better to define criteria first and then evaluate possible solutions against them. What is more important for your code - to be fast, correct, easy to understand, fix or extend? How each possible solution scores on these scales?

⬐ mistermann

Code it each way and post it online and someone will tell you with absolute certainty that you are Doing It Wrong because <some fashionable pattern>. Take this person's recommended implementation and post it online and someone else will tell you, again with absolute certainty, that you are Doing It Wrong because <some other fashionable pattern>.

All the while never mind that in 9/10 cases you could have written it either way and it would be of sufficient quality and performance, run more or less without issues for years, be conducive enough to periodic refactoring, etc.

I have a similar feeling as you about software today, although I'm not sure if for the same reasons. I look around me and everything is just so damn complicated. Writing code that is small and understandable is ruthlessly mocked, while a gigantic, complex marvel of engineering (that does the exact same thing) is looked upon as The Right Way. Functionality that would take a week or two to implement 15 years ago now takes a month, or three.