JJinuxLand

I recently found a bug in react-css-modules that prevented me from upgrading react-mobx which prevented us from upgrading to React 16. Then, I found out that react-css-modules is "no longer actively maintained". Hence, whether I wanted to or not, I was kind of forced into moving from react-css-modules to babel-plugin-react-css-modules. Doing the port is mostly straightforward. Once I switched libraries, the rest of the port was basically:
Get ESLint to pass now that react-css-modules is no longer available.Get babel-plugin-react-css-modules working with Less.Get my Karma tests to at least build.Get the Karma tests to pass.Test things thoroughly.Fight off merge conflicts from the rest of engineering every 10 minutes ;) There were a few things that resulted in difficult code changes. That's what the rest of this blog post is about. I don't think you can fix all of these things ahead of time. Just read through them and keep them in mind as you follow the approach above.…

As usual, you should check out the CHANGELOG. However, let me point out a few things specifically:

If you have something like: observable({ @computed get someProp() { ... } }); your code will work in 2.6.0, but in 2.7.0 reactions won't occur properly. Your tests will end up timing out. It needs to be: observable({ get someProp() { ... } }); Note, there's no deprecation warning or anything. Also note that this doesn't apply to situations where you're using a class. Those will continue working as before.

As of 2.6.2, toJS no longer recurses once it hits something that isn't observable. Hence, if you have an observable object with a non-observable array with observable objects in it, MobX will only convert the outer object "to JS". You'll need to call toJS again for the things inside the non-observable array. This can cause painful to debug errors.

This change was announced for 2.6.0, but it actually happened in 2.6.2 which means that upgr…

I spend a lot of my time refactoring code across a very large, legacy codebase at work. Often times, I'll do a search for something and work my way through the results over a period of days. Sometimes, something I see might lead me to do another search and a minor refactoring job which is part of the overall refactoring job. Hence, sometimes I end up with a "stack" of different searches which represents all the parts of the overall refactoring job. In each of these search results, it's important to not "lose my place" as I go down the list.

WebStorm / IntelliJ / PyCharm support this workflow really well:

Notice, I have multiple search tabs open at the same time (which is missing from VS Code). I can cross things off the list (which you can do in VS Code via deleting the item). And I don't lose my place in the list when I edit the code (another key benefit over VS Code).

NetBeans also lets you have multiple search result tabs at the same time.

It's …

I spend a lot of time futzing with editors and IDEs. To be honest, I'm pretty compulsive obsessive about the whole thing. I can watch YouTube videos for hours studying how each works and why people like them. One question that I really wanted to tackle is "Are there ways in which VS Code is actually better (i.e. more productive) than WebStorm, PyCharm, IntelliJ, etc."

I think this video Moving from WebStorm to VSCode does a pretty good job tackling this question, but I remain unconvinced.

I think there are three things I miss the most in VS Code compared to PyCharm, WebStorm, IntelliJ, etc.:

1. The Find window is much better in PyCharm. I can search for something in order to do a cross-project refactor. As I go through each entry, I don't lose my place in the find results, even if I have to edit the code for a few minutes. (Trying to do the same in VS Code is a fairly frustrating experience.) If I need to search for something else, I can save the results in a new…

Here are my notes from Chrome Dev Summit 2017:Here's the schedule.Here are the videos. KeynoteBen Galbraith and Dion Almaer, Director, Chrome Web Platform and Director, Developer Relations@bgalbs and @dalmaerThis was the best talk of the whole conference. They covered a lot of new stuff in a very short amount of time. This one talk is the talk that's the most worth watching.They plugged PWAs (Progressive Web Apps).Lots of browsers support Service Workers. It's still in development for Edge and WebKit, though.Workbox is a library they built for working with Service Workers. It's used by 70% of the sites using Service Workers.They plugged letsencrypt.org.64% of traffic is transmitted over HTTPS on Chrome on Android.They're going to start marking any form that isn't submitted over HTTPS as not secure.Use autofill completion hints to help out Chrome with autofill.They plugged PaymentRequest. It's a payment UI that is built into Chrome itself. It cuts down the tr…

You know that problem about there only being two hard problems in computer science? Today, I broke a page in production because of a cache invalidation issue when I tried to rename something.

I have a real soft spot in my heart for C, and I really do think there are still some valid use cases for C. However, in most cases, you should use something higher level. Case in point:

I was watching a video on C called How I program C. Here's a screenshot:

The video was highly recommended by someone. However, at some point he said (roughly), "I'd rather have 100 lines of C code that I wrote myself than 2 lines of mysterious code in a higher level language because I'll at least know exactly what's going on in the C code, so there won't be any bugs hiding."

It really made me think, where are bugs more likely to hide? 2 lines of Python or 100 lines of C? What about 2 lines of Go code?

Anyway, I was surprised that he said he said he only spent 20 minutes a year fixing memory leaks in his C code. Hence, I decided to peruse the comments on YouTube:

Yeah, ok, I'm done.