jake_morrison

I have been using mutt for triage and simple things, with Google web mail interface when necessary for e.g. HTML mail.

The workflow is ok. I get a large amount of email that I can just delete, and it's particularly nice to be able to select a bunch of cron emails with a regular expression.

In the last year it's become unreliable. When I move a message from one folder to another, it doesn't stay moved. I guess it's some error handling problem. I have lots of emails in some folders (10k).

I have thought about writing a driver for mutt that works directly against the Google API instead of IMAP, but writing REST code in C would be a slog.

I use Arq with Backblaze B2, which costs about 1/4 as much as S3.

https://www.backblaze.com/b2/cloud-storage.html

Long term, the aging population means that the US needs immigration to keep things going.

The politics are nuts, keeping people out who would do the jobs and not providing a path to citizenship. And they make it hard for people who come to study to stay.

The aging population is the same all over the world, and there will be competition for young, talented people. These policies will kill US competitiveness in the next 10-20 years.

In my home town in Oklahoma, the worst offenders are the churches. Huge parking lots which are only used on Sunday.

It should be possible to get the birth certificate eventually, though Covid will slow things down.

My father died in Thailand without a will, and settling his estate involved proving that I was the only person left to inherit. That meant a very long chain of authentication of birth certificates, death certificates, and divorce documents.

For example, I ordered my grandmother's death certificate from the city of Chicago, got it authenticated by the Illinois Department of State, got that authenticated by the US Department of State, got that authenticated by the Thai embassy in the US, got that authenticated by the Thai government in Thailand.

Repeat for for another dozen documents. I was able to do it all remotely, by mail, but it took more than a year.

When it was all done, I went in front of a judge in Pattaya in Thailand. I was worried that some Thai lady would suddenly appear claiming to be his wife (I suppose that happens at least once a week there). But in the end it was anticlimactic.

Twitter has a huge problem with bots.

On one hand, there are a lot of bots which are more or less malicious, e.g. trying to cause political strife or promote scams. On the other hand, Twitter sells advertisers on the idea that they have however many millions of users. So if Twitter was to actually get rid of the bots, then they would cause advertising revenue to drop, which might actually kill the company. So they are stuck with algorithmic techniques which walk a fine line of accuracy.

The solution is probably to mass verify real users (though "real name" verification is problematic). Right now, they use verification as a way to play favorites. Real users with hundreds of thousands of followers can't get verified.

To some extent, Postgres just follows the path that Oracle did to optimize performance. To see what Postgres needs to do next, just look at what Oracle had to do.

Postgres forks a listener process for each connection, which is relatively heavyweight. Oracle used to do that, but implemented a separate multi-threaded listener process for performance reasons. MySQL is multi-threaded from the beginning.

I spent a summer in India in the late 1980s (Tamil Nadu). Going between cities, the roads were only partially paved. There were two dirt lanes, with a blacktop middle lane. The trucks would play a continuous game of "chicken", driving at each other until someone lost their nerve.

The newspaper had regular reports of truck "capsizings", where a truck would lose control and turn over. It was common for a truck to have laborers who would fill up the truck with some bulk product like dirt, then ride on the top to go to the destination, then unload it. When one of these trucks capsized, it was a major disaster.

There are a lot of downsides of working from an office that were ignored when everyone had to do it, e.g. time wasted in commute, expensive housing because of the commute, getting colds all the time, being forced to interact with creepy people.

A proper office can be more pleasant than your home office, but most of them are not that great, e.g. you rarely have a quiet place focused on work, instead it is a noisy shared space. The business people say it is because of improving collaboration, but a lot of it is due to cost.

There is certainly value in being able to have face to face meetings, low overhead processes such as daily standups and pair programming, and build relationships with co-workers over lunch.

The biggest value in working from home is that you can fit work into the rest of your life, e.g. taking care of kids and reducing costs. Making people come into the office one or two days a week breaks that value.

The challenge of remote work moving forward is to try to build processes to reduce friction in online collaboration and to explicitly give space for team building and personal aspects.

It's pessimistic to think that we won't figure out some solution to reprocess nuclear waste efficiently in the next 50 years, to say nothing of the next 30,000 years.

And I don't hear people talking much about the problem of "solar waste" and "wind waste", i.e. what are we going to do with all the obsolete solar panels and wind turbine blades in the next 20 years?

The debt limit is a completely artificial, political game. Congress passes laws which have costs associated with them. Then they, separately, decide whether they will authorize payment for those laws. The costs should be automatically authorized.

Republicans get to score political points by pretending to control spending, when in fact they raised the limit every time they wanted to give tax cuts to their wealthy donors. It's hostage taking, because they understand that the Democrats will act responsibly. They get to threaten to destroy things as a negotiating tactic.

Beyond a certain point, test coverage has diminishing returns.

You end up testing failure cases which are better addressed by good error handling. For example, inability to open a file due to file permissions can be covered in a more general way.

Erlang is one of the most effective platforms for making reliable software. It has the concept of "supervisors" which will monitor and restart code if there is a problem. This handles both known problems which are appropriately managed by the standard strategy as well as unexpected problems.

You can also use other static code analysis tools that ensure that you have dealt with every possible return code from a function.

Other things become more useful than testing, e.g. implementing observability to tell you what is happening at runtime.

Instead of more unit tests, I would prefer to have more validation checks when deploying code and in production. A validation check for Blue/Green deployment prevents bad code from going live. A production check ensures that nothing bad is happening that affects users, e.g. if we would normally get 10 signups per hour, and we are now getting zero, then it's time to page someone. I will take that over an extra 10% code coverage any day.

Put the effort that you were going to use on code coverage into something that gets higher value.

Too busy arresting people for victimless crimes like smoking pot.

Twitter seems to be cracking down on bot-like behavior. I recently had my twitter account suspended.

It seems to be related to using the new function which suggests that you follow a group of related people with one click, e.g. digital artists. Seems I followed too many people in a short period of time. Make up your mind, Twitter , do you want me to follow people or not?

I was attracted by the specs of the previous version of this board, but the software side was a real mess. I screwed around with it quite a bit, but ended up giving up on them.

The company didn't have a reasonable, up to date kernel. Everything was out of date, and they were seemingly incapable of doing it. MediaTek people stepped in, because the board was getting press as a reference for how people could use their SOC. It was still not usable as a router. For example, while there is WiFi on the board, there is no Linux WiFi driver, only an Android driver. And other weird things that I forget right now.

Maybe things have improved, but definitely take care on this.

VoltDB is a good example of rethinking relational databases for for modern technology. Traditional databases assume that everything is stored on disk, with a bit of RAM available for cacheing. VoltDB assumes that everything is stored in RAM first, using checkpointing to disk and replication to get durability.

https://www.usenix.org/legacy/events/lisa11/tech/slides/ston...

Have a look at Michael Stonebraker, he's a database genius, and keeps starting "NewSQL" companies which use the relational model, but specialized for different applications, e.g. column stores.

https://en.wikipedia.org/wiki/Michael_Stonebraker

That's incorrect, there is no serialization when sending messages to processes that are on the same machine. (Otherwise it's transparent to the application, though of course there are performance impacts.)

To the programmer, messages are immutable. There are, however, optimizations to reduce the performance impact, particularly for binary data. When you send a binary message that is longer than 64 bytes, it is actually stored in a shared heap and effectively only a reference is passed as a message. Similarly, when you extract a small piece out of a larger binary, you might actually get a reference to the larger data stored on the binary heap. The Erlang VM has had more than 30 years of development, and there are a lot of subtle optimizations like this which were needed to solve real world performance and scaling issues.

Lack of serialization is one thing that makes e.g. the ETS key/value store built into the VM nice compared to Redis. You can just use raw data structures as keys and values. Reads and writes are under 1 microsecond.

I would have loved to have that when working on building AMIs for custom Linux systems, e.g. https://github.com/cogini/buildroot_ec2 and https://github.com/cogini/nerves_system_ec2

I spent a lot of time looking at console screenshots of machines that would not boot and iterating to figure out the problem.

That's a good example, but I would not want to overstate the need for recursion. Most people look to the standard patterns in https://hexdocs.pm/elixir/Enum.html unless they are doing some custom control flow.

Pattern matching is really helpful, though. It turns complex nested logic into simple truth tables and acts like Eiffel's design by contract, just pattern match on valid inputs, then handle the errors.

The same functional patterns repeat at different levels in the stack. For example, in the Phoenix web framework, processing a HTTP request can be considered as pattern matching on the expected inputs (validating them), then a series of transformations (making a db request, taking the result and rendering it into HTML via a template), then returning the result.

From a concurrency perspective, the interesting part is that each HTTP request runs in its own separate blocking process (green thread). So when you are doing the programming, you don't need to think about concurrency and async stuff. You just do your thing. This makes it easy to think about and debug.

Elixir/Erlang has some of the most mature ways of interoperating with external code of any language.

It's literally what Erlang was invented for 30 years ago, building telephone switches where the main logic was on the Erlang VM, interfacing with logic in C which interfaces with the switch hardware.

There are multiple ways of doing it, each with different tradeoffs of safety and performance. You can write FFI code using NIFs, but the Erlang culture of reliability frowns upon it unless you have real performance needs. A good example would be doing cryptography. If the FFI code needs to handle concurrency itself, it can, communicating with Erlang/Elixir via messages. You don't need to care about the threading model. But that's generally not a great architecture. You should rely on the VM's processes to handle concurrency and make the FFI code just be libraries.

It's very common to write performance critical code in a compiled language such as C++ and talk to it over a "port", which spawns an OS process and communicates with it over stdin/stdout. An example is high frequency trading, where Erlang is used to supervise low level code.

You can also write a "C node" which allows a standalone program written in C or Java to talk the native Erlang network distribution protocol. So you just send messages to it.

This kind of thing is very common in Elixir embedded systems, and a joy to work with. See https://www.cogini.com/blog/elixir-and-embedded-programming-...

Another success story for Elixir/Erlang. If you are building chat apps with anything else, you are doing it wrong. :-)

PHP used to actually have a performance penalty for splitting things up into modules and using object oriented design, because it meant loading and parsing more files on each request.

I was trying to do that on my first big PHP project, and got called out. The architect said "your code is too good, PHP is for writing crap". If you are going to write good code, you should do it in another language.

Symfony framework is a great example of a PHP framework written by Java programmers. All the same verbosity as Java, but without the benefits of Java.

I keep a small collection of applications where I think blockchain applications actually make sense. So far, most involve things where transparency in a distributed network is very important:

1. Running a lottery over the Internet. There are a lot of people who would be happy to buy a share in a typical national lottery as long as they could be sure they were not getting cheated. I don't care if e.g. 10% of the money goes to fund schools, as long as it's fair and transparent.

2. Internet gambling. If I bet on something, I want the odds to accurately reflect the bets of all the players, and I want to be able to get my money out if I win.

3. A currency for use in online advertising. A lot of the money that advertisers pay mysteriously disappears into the hands of middlemen before it gets to the sites that host the ads. There is also a lot of fraud. Having a transparent and accountable system would make it more effective for people who are not parasites.

Anything else?

I agree. Something that would help would be focusing on dealign with saboteurs and small unit attacks, and making it difficult to hold the island thorough guerrilla warfare. There is no indication that they are doing that.

Even more effective for China is to simply invest a few billion Dollars into bribing politicians. Some would argue that this has already been done with the KMT. They can also put pressure on the owners of the first generation of factories in China, which tend to be related to KMT. They will give up Taiwan in order to keep their business.

It's a bit nuts to try to estimate software development. People want certainty that they can't actually get. Some will even overpay 2-3x just to have it be a fixed number. Having a good process for managing change and accountability is key.

In the case of UpWork, a friend in California was not particularly price sensitive, he just didn't like the bullshit. Every project would involve Skype calls in the middle of the night. He would ask for something for his website and someone would bid $500, then come back and try to fight for another $100. But if they bid $600, they would probably lose. You post a job and there are 100 similar bids. So you just choose the cheapest from the first page or two. Anyone who put any thought into the bid is on page five. And the cycle repeats.

The structure of UpWork means that most people are inexperienced or scammers.

Developers start out doing freelance work with no history, so they bid low to compete. Once they do a few projects, they start to get direct referrals at higher rates without the UpWork percentage, so they leave.

Other people make bids at say 80% of the real cost of doing a project properly, planning to fight with customers to get more money later, e.g. claiming that things are not in scope. Once the customer is hooked, then there is more room to make money.

The platform incentivizes developers to respond fast with low bids, without thinking. If the requirements are not clear, then it's too risky for them, unless they are prepared to fight or play bait and switch games.

Customers can also play games, e.g. threatening to give a bad rating unless developers do more work. So it's hard for developers build a good reputation on the platform.

So the end result is that UpWork is primarily low-end, well-understood work like WordPress done by people in super-low-cost countries like Bangladesh. Everyone good leaves the platform for higher paying work elsewhere. But UpWork makes customers think that there is some magical source of great people at a low price, setting unrealistic expectations.

The biggest problem with new product development is that the requirements are inherently unclear, requiring insight and iteration to get right. You are doing something that hasn't been done before, by definition. Just translating the business opportunity into a detailed product spec that can be implemented can be very challenging. Until you have that spec, you can't use low end outsourcers. And then you will probably need to change direction based on customer feedback. So anything fixed price is going to be a problem, but you still need to keep things under control.

If you are a non-technical founder, then this is really hard, and you need to find someone who can bridge the gap between requirements and solution. There are product-oriented consulting companies (like mine) which focus on this problem. It's quite different from traditional outsourcing and freelancing, though.

I expect the additional cost of salaries of US CBP officers in Taiwan is negligible in the larger scheme of things. I imagine this is part of a bigger plan to do more pre-clearance globally.

One advantage of doing pre-clearance is that aircraft can go from Taiwan directly to other airports, bypassing overloaded airports like LAX. In a post-COVID world, they can also avoid having people arrive sick. The Asian countries have done much better with Covid, and keeping them separate would be a win.

There is probably also more customs pre-clearance of freight going on, and a lot of air freight goes via passenger aircraft.

Back in the 90s I developed a new HR-related web application for a customer in China. Then we found out that they still had a significant number of users on serial terminals, basically a VT-100 with support for Chinese characters.

So I made the app work with Lynx text mode browser. Magic getting the Internet on a serial terminal.

There is also a funny effect which is driving Python to be the most "popular" language. Someone will post a job advert for e.g. Java, and list Python as being one of the "nice to have" languages, either due to machine learning, devops, or just because it's nice to know a scripting language. Python is currently the nice to have language. So you see it on the list of hot languages, but in fact there are not all that many Python jobs, they are all actually e.g. Java jobs.

I have been using Erlang since 2008, and started using Elixir in 2014.

I much prefer the Elixir syntax. It files off the rough parts of the Erlang syntax, e.g. needing to keep track of commas, periods and semicolons at the ends of lines. The most important thing Elixir adds, though, is lisp-style macros, which makes everything else easier.

This is the post which made me switch to Elixir: https://littlelines.com/blog/2014/07/08/elixir-vs-ruby-showd... We get the best of both worlds: the ease of use of Rails with the power of Erlang.