jweir

There are many. My kids read them in fourth grade - this particular one I had not seen before. Lots of fun.

This is wonderful – however I feel a bit sad that is a museum rather than an active place people live. So many examples of wonderful architecture in California, but they are museums, and around them are built sub par structures.

This is probably a design oversight, a week or two ago, the prices were available for the production releases.

No, it is that mocks can hide interface changes. So if you have a mock, then you need to test that the interface works without the mock. And if you are doing that, why not just skip the mock?

foo calls x(user, date) foo mock # tests pass

x changes to x(user, time)

but the tests for foo do not change, tests still pass, runtime errors.

If you have static/strong typing the compiler will pick this up – but for dynamic languages you have a problem.

Own your process – at best that CDN is spying on your users.

I tell my developers that each mock you use costs you $100. Maybe it is worth it, but probably not.

No I don't really charge em – but it gets the idea across that mocks have costs that you don't always see up front.

sass expands the nesting ie

  .foo {
    .bar {
      color: red;
    }
  }

becomes

  .foo .bar { color: red; }

The first case modern browsers can handle, but versions of Chrome upto some in early 2023 still can't – and that includes a lot of Android installs as I experienced.

Once those browser versions roll off we will be able to remove sass altogether.

Anytime we make a change to a screen we opt to upgrade the CSS template. So, only if we are working on that part of the application.

Typically it takes just a few minutes to switch out the CSS.

Now, there are a few very complex screens that require more effort (a lot of data viz and variable state). Those we evaluate - maybe we will punt on the upgrade – or maybe we dig in and do it if there is nothing urgent on the books.

Our application has been on an old version of Bootstrap. And for sometime we have been evaluating different frameworks and libraries as a replacement. But they all feel huge and complicated.

My CSS knowledge was still stuck in 2010, with a bit of learning since then. So after seeing some impressive modern one liners I decided to look into modern CSS and compatibility.

It took about a week to write a new, very clean and very simplified CSS style sheet to replace Bootstrap. We own it, since it is tailored for our app we don't need to use many classes (the HTML element defines the style). The sheet is about 1000 lines of CSS, 50 lines of Javascript, and supports dark/light mode.

First we replaced the navbar – a global element. Now we are replacing screen by screen with the new style sheet.

It uses modern CSS nesting – but we still run it through sass because enough customers are using Android or older versions of Chrome that don't support the nesting. Otherwise we haven't had any reported problems.

MDN is a fantastic learning resource for all of this.

Oklo does not have an approved design. They have applied and are awaiting approval.

https://www.nrc.gov/reactors/new-reactors/advanced/who-were-...

Elm makes great use of these, for example in the Units package:

https://package.elm-lang.org/packages/ianmackenzie/elm-units...

Very nice to prevent conversions between incompatible units, but without the over head of lots of type variants.

https://thoughtbot.com/blog/modeling-currency-in-elm-using-p...

“When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”

Ah - all is clear ``` [flagged] [dead] Marc Andreessen Is a Maniac (gizmodo.com) ```

This story was on the front page of Hacker News – but then disappeared. Did the original poster delete it or something else happen?

It is very experimental as well. An interesting language, but say good by to tried and true tooling since the code exists as records in database, not files.

This could lead some huge advantages, and new obstacles.

I played with the language for about a week and found it intriguing. And it seems to approach tackling Joe Armstrong's question "Why do we need modules at all?" -> https://erlang.org/pipermail/erlang-questions/2011-May/05876...

If you are considering hiring and the hire is a developer or at all involved in research and experimentation make sure you are well versed in Section 174.

You could be on the hook for a large tax bill since you have to write off developer expenses over 5 years – this is true whether an employee or contractor.

Hopefully it will be repealed* – but if not it is one of those things that no one would expect to exist since it is in the words of Senator Wyden "stupid."

https://www.law.cornell.edu/uscode/text/26/174

* edit It won't be repealed but a law can be created to ignored it until a future date. Once on the books, because of accounting, it is very hard to remove a tax law.

We ban most meta programming in our own code. While the meta programming solutions are fun and clever they are often more code than a functional version and hard to maintain.

We do allow the occasional use of “send” but try to avoid it. Dynamic method definitions are strictly banned.

Bingo.

There is nothing wrong with using NOW(), in of itself, and it maybe the best thing to do.

But it may lead to surprising results when say you have an application that has mocked out time for a specific time, but you get db results for the current time. It introduces another clock into your system.

I have found most of the time we were using NOW() we could pass the time into the query and create a more understandable chain of code.

When possible pass the time as an argument and create pure functions or methods.

Reserve Time.now or its equavlent to jobs, controllers, or what not at the edge of your application.

Watch out when using NOW() in your db. Not that you shouldn’t but it might be surprising when you do.

Since Ruby 3 I would recommend trying again. It is much faster now.

Back in the Ruby 2 days we had tools like Zeus to preload our development application because loading was so slow (10-20 seconds). These days we just load the whole app (2 seconds)

These benchmarks show a 2x speed up. While I haven't see that, I have seen at least a 50% increase in performance for our applications.

We kept YJIT off for 3.1, but turned it on for 3.2. I am working from my memory here, but I recall 3.1 not performing well with YJIT.

We saw memory go up when moving from 3.1 to 3.2, but we also removed compiling Ruby with jemalloc and used the defaults. We have seen performance increase by about 10% for our web applications. Our forking background processes run about the same. YJIT appears to perform for repeated requests – ie first run will not expose any benefit, ie your tests won't run faster.

[edit, the memory increase was small just a few percent IRC]

The entire Midwest Energy Market (MISO) does not use DST, but not by disabling it but by setting their org's timezone to EST.

On one hand this simplifies a lot – days are always 24 hours for example.

But it does complicate interop outside of the market since energy is traded with DST based markets, and gas is bought using the gas day clock (also DST). The gas day starts at 10am eastern prevailing time, eg. 9am is yesterday, 10am is today.

"My rake is faster than your leaf blower"

https://www.youtube.com/watch?v=r-XqbXi7tNo

I am pretty sure it is limited to the desktop OS.

it is the Keychain Access app

Yes, you can create a "New Secure Note Item"

I love it, a video TLDR for classic (and not so classic papers). Thank you.

The bowline, because of the rabbit, is one of the only knots I have not forgotten from my scouting days.