Skip Navigation

  • Possibly. My point is: despite having a common subset Pkl and JSON schema doesn't seem to be solving the same problems. But, I'm just learning about it, so I may just be wrong.

  • I just learned about Pkl, so take this with a grain of salt. JSON Schema and Pkl seem to have some overlap. But JSON schema is not specifically designed for handling configuration and Pkl supports other formats like YAML.

  • This looks really interesting. Getting type safety and editor support to configuration may change quite a bit of how things are done. I don't know if it will gain traction, but if it does, it may really help bringing some long awaited structure to all those YAML files. There appears to be examples specifically for Kubernetes (https://github.com/apple/pkl-k8s-examples).

  • I wasn't aware of that. I guess it was thought to be a mod driven community. Anyway... Cool question. I hope we will see some creative solutions here.

  • The longest I worked for a company is around 6-7 years.

    As long as you get the opportunities to develop your skills in the areas you want (so that they are still relevant in the job market) and there is a good team around you, it doesn't make sense to change jobs just to change jobs. It's generally difficult to get a meaningful salary increase without a job change and that's the main reason most people are looking for new jobs, I think.

  • The first time I saw that prompt, I thought the same. "I don't want to cancel the install, I want to install it." You get used to it, but I don't think this is a very good UX.

  • Thanks for the explanation. If it works, don't fix it :)

  • I used Google Sites a long time ago and I'm a bit surprised it still exists (with Google killing products all the time). How is it with revision history, etc. Is it easy to download the contents in a reasonable format? One advantage of GitHub/GitLab is that you have all your archive in source control all the time.

  • If I was to create a blog today, I would use a static page generator and host it on GitHub or GitLab. I would spend my time on creating original content instead of tweaking the infrastructure.

  • Are you interested in working on a text editor? If so, I have an idea I plan on implementing myself for fun: a clone of HeyNote with some added functionality. HeyNote is a simple buffer that consists of blocks. It's useful when you just want to note a simple block of text (an SQL query, log output, test data) but you are not interested in structuring it. What HeyNote lacks is the ability to add title and tags to blocks. It's not an alternative to other note taking applications. It is just a buffer with unrelated blocks in it.

  • That's explained at the end (Revisions). Fowler is probably looking for a general term that can be used to describe this specific way of debugging. Since he is aware of git bisect (and I'm sure he knows about hg bisect) there must be a reason he is not preferring "bisect debugging," for example.

    Edit: The term diff has a clear link with version control. bisect is not that obvious. It may be ambiguous/vague in debugging context. I would still call it "bisect debugging."

  • Watching Brandolini is fun. He always have fun slides to look at and a humorous way to express his ideas. This talk is no exception. There are two things I would like to highlight:

    1. Brandolini thinks using Lo-Fi tools (like sticky notes, pen and paper) is superior to digital alternatives because when using them you focus is modelling instead of tidying the diagram. He says: "Digital tools are changing your brain priorities. I enter a session to model, and I find myself aligning rectangles and making arrows clear."
    2. Following the domain expert wherever they go is not necessarily a good idea. In many cases, the domain expert will push for a quick fix in the system instead of aligning the code base with the business and that will not be beneficial in the long run.

  • Great news! Looking forward to testing it.

  • The book was published in 2010. And for a 13 year old book it certainly feels old. This is a compilation of short articles written by several people. And they generally do a good job of articulating their thoughts, but I cannot say it's full of gems, or anything. There is obviously some good advice. After all they are all experienced people with a good understanding of the field. But there are also sentences like "Do not only measure test coverage, but automatically check the results, too. Again, break the build if test coverage is too low." or "Have a regular code review day each week. Spend a couple of hours in a review meeting." So... I think it makes good light reading. You can read a single of these 97 "things" in a couple of minutes. But I wouldn't keep my hopes very high.

    BTW: The book is available in GitHub: https://github.com/97-things/97-things-every-programmer-should-know

  • Beginning in Git 2.43, Git will realize when it’s about to perform a double-revert, and instead produce the much more pleasing message

    Doesn't happen very often, but I'm glad we have a better solution to this now.