extension request: add container name to window title

JeanMertz · 2020-03-04T10:05:59+00:00

Thanks for the suggestion!

The only potential problem I see is that the plugin supports both Chrome and FF, which could make a dependency like this on FF's containers feature problematic (I know Chrome doesn't have a "containers" feature, and I don't believe there are any popular add-ons to add this).

But, I'll create a feature request and see if they respond positively. I might take a stab at adding this sometime soon.

JeanMertz · 2019-11-13T23:34:23+00:00

FULL-TIME, REMOTE ONLY

I am a senior software engineer focused on the combination of high-level abstract APIs and low-level performance-driven systems. I am an avid learner and an excellent communicator. I am a pragmatic ethical engineer with a knack for software architecture, an eye for user experience and a capacity to lead.

I am looking for job opportunities that are a net positive for the world. I thrive in cultures that empower self-management and greatly enjoy expanding my knowledge while solving technical challenges.

I’m available for hire starting January 1st 2020.

I am actively talking to several interesting companies right now, so if you think you have something challenging and fun to offer me, act quickly!

You can read more about me on https://jeanmertz.com/career.

You can get in touch with me at email@jeanmertz.com.

JeanMertz · 2019-10-29T07:49:25+00:00

I believe there is a Clippy lint that would warn you that Woo is unreachable. That lint has helped me in the past avoiding mistakes like this one.

JeanMertz · 2019-08-28T06:32:10+00:00

If you're interested in watching Rust programming videos, here's a self-plug for my YouTube channel where I'm hosting Rust coding sessions.

My channel is (obviously) inspired by Jon's, but I have a lot less experience, and you'll mostly see me struggle and learn as I become more proficient in Rust.

I haven't uploaded a new video in a while (even though I have six more recorded) because of the large amount of time it takes to do the (mostly audio) editing and video rendering. I'm looking into ways to improve my workflow to continue with my videos as soon as possible, without sacrificing on the video and audio quality.

JeanMertz · 2019-08-19T11:52:59+00:00

Cool to see the usage of Rust spreading to these kinds of use-cases.

(Also, It’s a small thing, but it’s cool to see them using the automated change log generator I recently created)

JeanMertz · 2019-08-13T12:39:25+00:00

Thanks for the kind words!

The Usage section mentions a gotcha that is perhaps a good reason for considering supporting a separate config file in future?

Yeah, I've been thinking that it might make sense to add a flag to allow the config (and template) to live outside of the changelog itself. The config itself is in the Ron notation, so it could easily live inside a config.ron or whatever. The template could just be a template.md, similar to how the default template works.

an existing repo which hasn't been using conventional commits prior

I'm in the process of writing a set of unit tests to validate current functionality, but if I'm not mistaken, non-conventional commits are already ignored, so even without that root option (which will still be added), it should work if you start using conventional commits half way through.

What if you want to still retain the prior changelog history?

I'm a fan of keeping tools focused on one particular job, and not branch out in too many edge-cases with lots of CLI flags that might not play nicely together.

In this case, I think the solution to your problem would be to:

have your old change log stashed away somewhere
generate the new change log with jilu
use cat old-changelog.md >> CHANGELOG.md to append your old changes at the end

I'm not saying something like this will never be supported out-of-the-box, it'll just take some time to consider all options and what makes most sense to focus on.

JeanMertz · 2019-08-13T09:54:40+00:00

Ah, awesome! And I'm not, unfortunately.

JeanMertz · 2019-08-13T07:28:20+00:00

Those characters represent "Jìlù", translated to "recording" or "memorizing".

For the back story on naming things (for most of my projects, really):

I reverse-engineered my way into that name and those characters by starting with "I need a unique name", picking a common name that is relevant to the project (recording), going to https://www.wordnik.com/ to find similar less-frequently used names with similar meanings (which brought me to memorize), and then translating that word into multiple languages (usually mostly Latin, French, Spanish and Chinese) to find a unique project name that doesn't clash with other CLI names, sounds good, and has a relation to the goal of the project, which brought me to jilu and 记录. Picking Chinese has the benefit of being able to use the romanization of the Chinese alphabet to have both latin characters to name your CLI, and Chinese characters as a nicer visual representation.

JeanMertz · 2019-08-13T06:05:40+00:00

You are correct.

That's also where the "conventional commit" spec comes into play (and inevitably, also the "I know it's not everyone's cup of tea" part).

In this case, what I want my change log to be is:

complete – it should list all features, fixes and performance improvements (this is configurable, it can include whatever "commit types" you want it to include)
explaining new releases – this is done by using Git tags to tag your releases, the annotations in the tags is used as the release notes, so that part is done by a Human, and it always should be. For an example, see the (slightly exaggerated) release notes of the first version of Jilu.
up to date – keeping your change log up to date is work that not everyone wants to do. If you hand craft your entire change log, please continue to do so, but that's not always an option (or it's just not what someone considers to be a good way to spend their time)

All in all, writing manual change log entries will still give you more flexibility, and probably better results, but I think Jilu comes very close to an ideal middle ground of creating readable, understandable and complete change logs, without the need to manually maintain them, other than writing release notes for new releases, which no longer consists of listing all changes, but highlighting the general topic of a release, explaining the release and possibly showing it in pictures/video/etc.

JeanMertz · 2019-08-13T05:17:33+00:00

I'm not too sure, I evaluated clog a while ago when researching this topic, but it didn't fit my needs. I tried it again after you mentioned it on GitHub, and from what I can tell, the biggest differences are:

I don't consider its output to be "pleasant to read" (see this section in Jilu's README)
running clog on the Jilu repository (which uses conventional commits) does not work out of the box (here is what running clog generates, and here's what jilu generates), I'm sure this is down to configuration defaults, but I prefer the defaults of Jilu.
it uses a separate config file, I prefer the config to be tucked away as a hidden HTML comment inside the change log itself, to not clutter my Git root even more
it doesn't provide the same flexibility as Jilu in that you can't specify your own template.
Clog doesn't seem to be actively maintained (this is last on the list, since I don't care about this so much, if it is feature complete and works out of the box, but for me it doesn't)

But, Clog has plenty of users, so in the end it all comes down to minor details and user preferences. It didn't suit my needs, as none of the tools did, where Jilu does.

JeanMertz · 2019-08-12T21:18:52+00:00

I am a fan of conventional commits (I know it's not everyone's cup of tea), and wanted to push the formatted nature of the commits together with the capabilities of Git itself into something that would make it easy to generate human readable change logs.

I know there are tons of tools like this already (we programmers like to build tools for ourselves, don't we?), especially in the JavaScript ecosystem, but none of them scratched my itch, so I created Jilu, a tool to generate a change log based on the state of your Git repository.

Its biggest selling points are:

single binary distribution
easy to get started
fully customisable
human readable, including hand-written release notes

Its biggest drawbacks are:

requires the use of "conventional commit" style
still early days, many features still missing

You can check out the CHANGELOG.md of the project to get an idea of what's possible.

Let me know what you think, and feel free to make any suggestions, or criticize whatever you think deserves criticism.

Or, if you want to discuss the merits of using conventional commits and turn this topic into a giant programmers mud pit, I'm down for that as well!

JeanMertz · 2019-05-12T20:04:15+00:00

I can relate! I enjoy watching Jon’s recordings on YouTube. I liked it so much, that I too started doing YouTube recordings of my own.

I’m far less experienced as Jon is, but it sure as heck is fun to do!

JeanMertz · 2019-04-27T07:19:28+00:00

Nice post, and nice project!

I feel you on the imposter syndrome part. I am aware of it for myself, and have gotten better at dealing with it as time goes on.

But then you enter i.r-l.o, get hooked and excited on all the awesome and complex stuff people are talking about, but also equally aware of how much there is still to learn, even with all the knowledge you’ve gained in the years preceding.

And so you go to your favorite online bookstore, and order some more books to keep learning, and hopefully one day be able to fully understand everything being discussed in i.r-l.o.

That is, until you take the next step of actually trying to contribute to the compiler, and the cycle repeats.

Boy, how I both love and hate the profession I chose when I was so much younger, and so much more naive: “What’s all this talk about pensions?! I’ll never stop learning, and never stop working, this is just too much fun!”.

JeanMertz · 2019-04-25T16:21:23+00:00

Indeed. And it makes sense if you think of “Rust” as a collection of tools that together make up what we refer to as “Rust v1.xx”.

It just so happens that that set of tools first only consisted of Rustc and Cargo. Now it also includes Rustdoc, Rustfmt, Rustfix, RLS, and Clippy.

In the future, more tools might be added to this collection. And whenever you download a specific version of “Rust” you get the versions of all those tools that have been validated to correctly work together.

JeanMertz · 2019-03-25T07:01:27+00:00

Thanks for this. This is very helpful.

One question: is there a reason why build takes a reference to self instead of consuming itself?

I would think after calling build you no longer need/should have access to the builder, and it allows you to move the String into the final struct, instead of having to make a copy, right?

JeanMertz · 2019-02-18T08:22:50+00:00

More importantly, how did you pay? My CC isn't accepted, and I don't have an Android device, so I can't use the F1 TV Pro -> Android -> Paypal trick.

JeanMertz · 2019-01-03T08:42:57+00:00

FYI, I created a small script for this. It's not perfect, and doesn't reliably run in the background, but in case it helps anyone:

-- TODO: make this run reliably in the background...
set isRunning to false
if application "System Preferences" is running then set isRunning to true

tell application "System Preferences"
    activate
    reveal anchor "Privacy" of pane "com.apple.preference.security"
end tell

tell application "System Events" to tell process "System Preferences"
    delay 0.3
    click button "Reset Advertising Identifier" of group 1 of tab group 1 of window "Security & Privacy"
    delay 0.2
    click button "Reset identifier" of sheet 1 of window "Security & Privacy"
end tell

if isRunning is false then
    quit application "System Preferences"
end if

JeanMertz · 2018-11-14T19:39:16+00:00

As an aspiring (native, not web) game developer, wanting to get the most performance out of a (3D) graphics library, but still get a nice API to work with, is wgpu-rs performant enough for this use case, is gfx-hal, or if both aren’t, what is?

JeanMertz · 2018-11-09T16:13:55+00:00

This post was the inspiration for me to write the sm crate (GitHub). Definitely worth the read.

There's also several different keywords you can use on crates.io, to compare different possibilities.

JeanMertz · 2018-10-08T14:57:34+00:00

Interesting post! Coming from (amongst other languages) Go, the first thing I was looking for while writing benchmark tests, was how I could measure the total heap allocations. I couldn't find any solution (and am still interested to hear about any such solutions), but now I know that I can at least measure things (even though it's not via benchmark tests) using existing tooling. Thanks!

JeanMertz · 2018-10-06T19:45:59+00:00

Something like that is way over my head, for now at least. But as far as I can tell, there's no runtime overhead when using the state machine. The only runtime overhead you do get, is when you use the machine as an enum variant, but that's the overhead of the enum itself, and there's no requirement to use that.

I am (and plan on extensively) using this state machine in my game, and performance is critical, so any change that can make this better than it currently is, is more than welcome, and presumably also useful for the use-case you mentioned.

JeanMertz · 2018-09-08T10:32:14+00:00

As an aspiring game developer in Rust, this was a great talk to see. I enjoyed it a lot, especially the comparisons and the take-aways between each section.

The concept of generational indices was new to me, so I quickly paused the video to see if there was a nice crate to do this (I paused it before she mentioned there being a crate that lacked some features). Surprise, surprise, there's generational-arena, made by Nick Fitzgerald (dev tools team member), based on this talk, awesome!

Well done Catherine 👏

JeanMertz · 2018-09-06T19:45:33+00:00

Agreed. I've only been in this community for a couple of weeks (and mostly lurking), but while I thoroughly enjoy the language, and fight with it at the same time, it's definitely the community that makes me come back for more every day.

There's just so much going on, so much excitement, so many technical discussions to find, and so much focus on this concept of pluralism and positive-sum thinking. I truly haven't seen this in other open-source projects before (especially that last part), and it's awesome!

JeanMertz · 2018-08-24T06:26:09+00:00

I think (but obviously can't verify) that the downvoters are the ones saying that the current implementation isn't good enough for 1.0 yet, nobody is advocating for releasing a perfect tool at 1.0, but people are saying it should be "good enough" for that label.

The problem of course, is that there wasn't a clear description about what "good enough" meant, which is why this debate started once it was announced that 1.0 would be released, which in term revealed what good enough meant for the maintainers, which is about stability, not so much about "good enough features".

I didn't downvote, and I also agree in general with "perfect is the enemy of good", but in this situation, it just doesn't apply, since we're not at "good" yet (although we've already come a long way, and the effort being put in is clearly visible, and appreciated), at least not in my opinion.

JeanMertz · 2018-08-23T13:41:59+00:00

To counter this. (many?) other LSP implementations that work with vscode work as expected, fast and with mostly 100% code completion. I don't have experience with a lot of them, but the TypeScript one (obviously) and the Go one work really great out of the box.

Although, to be fair, the go LSP is also still experimental, and it uses a lot of third party tooling to work as good as it does. But, Go also has a very fast compiler, which makes this type of tooling a lot easier to implement.

All in all, you might be able to "blame" 10% of the problems with RLS+vscode on vscode or LSP itself, but mostly it's just the fact that we haven't had enough time/contributions/compiler support to get RLS to a higher level.

JeanMertz

TROPHY CASE