Posts on Igor Klimer's personal site

Migrating from Create React App to Vite

Sat, 06 Jul 2024 22:08:50 +0000

This post is meant to document my process, thoughts and tips on the migration of my ReCalendar personal project from Create React App to Vite. It’s not meant to be an exhaustive guide. I wanted primarily to document the more interesting (and often frustrating) challenges of such a migration. So that others might benefit from them when scouring random pages on the web, searching for an explanation or solution to a cryptic error message.

Why migrate?

Create React App has been the de facto standard when creating new React apps for years. It’s still being recommended on many blog posts. However, it has not been actively developed for a year, it has >1.7k open issues and 477 pull requests. Mostly to update the out of date dependencies. In short, it’s not a future-proof solution.

As typical in the JavaScript ecosystem, there’s plethora of alternatives. I went with Vite, because it promised speed and simplicity. React.dev has a list of more complex, full-stack options, if that fits your requirements. However, ReCalendar is client-side only by design, does not need any routing, state management is very simple, etc. So Vite seemed like the best choice.

Simplified migration steps

Create a new Vite project, most likely using the provided templates. There’s official support for many frameworks, and the community has got you covered for the rest.
I was previously using yarn, but for the new project, I went with npm. My understanding is that npm caught up with yarn recently in terms of performance and other improvements. So no need for an additional dependency to install.
I also went with TypeScript-enabled configuration. It’s compatible with JavaScript (which the project is currently written in), but I’m hoping to migrate it to TypeScript in the future, so this gives me that possibility.
Copy the source code to the new project. At this point, I’m just trying to make things compile. I went with the simplest approach of just manually re-installing the needed dependencies. There’s not that many and since I switched from yarn to npm, it felt like a proper fresh start.

Gotchas

Overall the code did not require much changes. Most of them were related to how Vite is “leveraging new advancements in the ecosystem: the availability of native ES modules in the browser”. It’s a radically different approach to Webpack and Babel that CRA is based on. Vite uses Rollup under the hood instead.

The majority of the work was squashed into this commit. Two major challenges are covered in the next sections. Other than that, I’ve taken the chance to clean-up things like .gitignore or Eslint configuration. Some other changes/differences include:

CRA would inject the correct script tag to the main HTML file at compile time. In Vite, you simply reference your app’s entry point like [/src/index.jsx](/src/index.jsx).
The env variables are exposed differently too. For example, process.env.NODE_ENV === 'development' becomes import.meta.env.DEV (which is a nice built-in boolean). There’s plenty more options, including HTML env replacement and such.
In CRA, I had the root folder for the sources configured so that import statements looked like import PdfPreview from 'components/pdf-preview';. In Vite (or maybe in general now?), you’re supposed to have a clear prefix, for example: import PdfPreview from '~/components/pdf-preview';. Which makes sense and I kinda like - local dependencies are clearly different from global/external ones.
- I only changed the often suggested @ prefix to ~, which makes more sense to me as the “home” designation. ~ is obviously inspired by *nix conventions, while @ gives me flashbacks from configuring DNS zones.

Workers

Since PDF generation inside the browser, on the client side, is a very compute-heavy task, it needs to be done in a worker. Otherwise, the browser would hang for up to minutes at a time. So it’s a pretty crucial part of ReCalendar. It was also the source of some frustratingly confusing and misleading errors.

Starting with ReferenceError: $RefreshReg$ is not defined. Or it’s close cousin, ReferenceError: $RefreshSig$ is not defined. What was more bizarre is that it was coming from React components from the configurator. Ones that should not be needed by the worker. Turns out that I had some constants defined in those files that were being used in the PDF worker. Because, you know, magic strings are bad. And it made sense to keep those constants with the components that use them. However, it seems Vite (Rollup?) had troubles handling that and tried to load the UI dependencies (like @dnd-kit/sortable) that were not meant to be loaded in a worker. Resulting in the above confusing error.

The solution was simple: move the constants to a separate file. Now the PDF worker had a clear and simple dependency to load.

Next error was much simpler to figure out: Cannot use import statement outside a module. I just had to declare the worker as an ES module:

export default defineConfig( {
 // ...
 worker: {
 format: 'es',
 // ...
 },
} );

Day.js dynamic locale loading

A bit of backstory: ReCalendar has awesome community members that helped translate it into 16 languages 💖 However, there’s more that could be done! Prompted by a user issue requesting another language, I realized that while the configurator requires translations, most of the generated PDF is just days of the week and months. And user-provided strings (which, by definition, they “translate” themselves in whatever language/format they want).

This gave me an idea to simply expose all the available locales from Day.js. The change was quite simple. However, it relied on require to dynamically load the JS files with the selected locale. It needed a method that accepted strings generated from user input (locale selection).

The problem: Vite is built around ES modules. require is not available. There’s plugins to emulate it, but that’s another dependency. However, there’s [import()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import) for loading modules asynchronously. And Vite supports it. Perfect, right? Not quite. It does not work for files from node_modules :(

I’ve tried many workarounds - like creating a symbolic link to maybe trick the process. Even tried copying the files to my src folder - after all, they are small and don’t change often. However, they are not meant to be loaded from a different package like that, so that was a fail.

What did end up working was using glob imports. Through static analysis, they generate a list of all the possible paths to include (as long as you follow specific guidelines) and allow you to dynamically load from that list at run time.

That finally made the locale loading work. However, it required two more tweaks:

Needed to move the language change event to before i18next was initialized. Otherwise, language detection would run before the event handler is set up. Interesting race condition - this worked with CRA, probably due to luck/different timings.
Made the glob imports eager - meaning, they are preloaded. This was an admittedly a lazy and quick workaround to imports being inherently asynchronous now. Which messes with React, as the state change (Day.js changing locale) happens outside the state it monitors. Eager loading preloads them and makes the action synchronous again. Since the locale files are quite small and simple, I figured it’s worth the trade-off to finish this migration. And gives me a clear target for optimization in the future.

Performance comparison

Now let’s try to ask the question: was it worth it? (yes, yes it was)

	Create React App	Vite
Lighthouse metrics	Same	Same
Vulnerabilities	67 (39 moderate, 16 high, 12 critical)	0
`node_modules` size	215 MB	188 MB
Number of files in `node_modules`	42670	18154
DOMContentLoaded	279 ms	117 ms
Total app bundle size	3.69 MB	3.26 MB

This is not an in-depth comparison. I’ve just looked at a few key metrics. Important caveat is that CRA includes the kitchen sink and more. For example, lots of testing libraries. Which I don’t have a use for right now. Vite has Vitest as a separate dependency to add when I finally face the reality that tests are indeed useful, even if the development is mostly done by one person…

Page load

No perceptible difference. I have not tried to squeeze out the smallest bundle for this project (it’s on my TODO). So the bundle size is quite large (~3 MB). Then again, it has robust i18n, date and PDF capabilities. DOMContentLoaded was halved, but it’s already been quite low so hard to say how perceptible it is.

Then again, these tests were done quickly and on a modern MacBook Pro. I need to test them on lower-end machines, where these improvements could make a much more noticeable difference.

Lighthouse metrics

Same before and after migration. Like mentioned above, there’s potential for further optimization, but that has not been the focus so far.

Security audit

From all sorts of vulnerabilities to zero. Because CRA has not been updated in more than a year. And even then, it had outdated dependencies. Which leads to many alerts when running a security audit (npm audit or yarn audit). After the migration, the number simply went to zero, which is great to see.

Dependencies

13% less in size, but a staggering 80% less number of files. I’d guess this is related to the fact that Vite is written in Go, but also that CRA brings in a lot of dependencies around testing and such. Which are optional for Vite. I did not dig further into verifying these assumptions, though. I’ll leave that to the reader - or future me ;)

Conclusion

Based on these experiences and results, would I recommend migrating from CRA to Vite? Yes, definitely. The challenges and changes were not as extensive as I feared. All metrics improved. And I feel the project has more solid and future-proof foundation now. I’m excited to start working on some new features I’ve been postponing!

Use Midnight Commander like a pro

Fri, 01 May 2015 17:11:00 +0000

Check the discussion on Hacker News about this post for a lively discourse and more tips!

If you’ve used an *nix system, at some point you’ve stumbled upon Midnight Commander, a file manager based on the venerable Norton Commander. You’re probably familiar with the basic operations (F5 for copying, F6 for moving, F8 for deleting, etc.) and how to switch panels (ummm, the Tab key). But mc offers so much more than that. This article aims to show all the useful (YMMV) shortcuts and functionalities that are often overlooked. Most of them can be accessed using the menu (F9), but who has the time to do that?

Before we get started, let’s establish some facts. This article was written and tested on the following software:

Midnight Commander 4.8.13
GNU bash 4.2.53

Oh, and make sure you’re running a modern and UTF-8 friendly terminal - for example, rxvt-unicode.

Hold your horses

There’s actually one thing I’d recommend doing before you run mc. mc has the ability to exit to its current directory. Meaning, you can navigate the filesystem using mc (sometimes it’s easier than cding into that one directory buried deep down somewhere) and when you quit mc (F10), your shell will automagically cd to that directory. This is done thanks to the mc-wrapper script that should be bundled with your installation of mc. The exact location is dependent on your distribution - in mine (Gentoo) it’s /usr/libexec/mc/, in Ubuntu supposedly it’s in /usr/share/mc/bin/. Once found, modify your ~/.bashrc:

alias mc='. /usr/libexec/mc/mc-wrapper.sh'

Restart your shell, launch mc, change to another directory, exit and your shell should be set to that new directory.

Selecting files

Insert (Ctrl + t alternatively) - select files (for example, for copying, moving or deleting).
+ - select files based on a pattern.
\ -_un_select files based on a pattern.
* - reverse selection. If nothing was selected, all files will get selected.

Accessing the shell

There’s a shell awaiting your command at the bottom of the screen - just start typing (when no other command dialog is open, of course).
Since Tab is bound to switching panels (or moving the focus in dialogs), you have to use Esc Tab to use autocompletion. Hit it twice to get all the possible completions (just like in a shell). This works in dialogs too.
If you want inspect the output of the command, do some input or just prefer a bigger console, no need to quit mc. Just hit Ctrl + o - the effect will be similar to putting mc in the background but with a nice perk. Your current working directory from mc will be passed on to the shell… and vice versa! Hit Ctrl + o again to return to mc.
Ctrl + Enter or Alt + Enter - copy the currently selected file’s name to the shell.
Ctrl + Shift + Enter - same as above, but the full path is copied.

Internal viewer (`F3`) and editor (`F4`)

The internal viewer has many built in modes for “previewing” the content of the file. Try “viewing” a binary, an archive, a DOC document or an image. In some cases, external programs are needed in order for this “previewing” to work.
If you want to preview the “raw” contents of the file, hit Shift + F3.
While the internal viewer and editor are powerful, sometimes you want to use your preferred software (cough_vim_cough). You can do so by setting the PAGER (for viewer) and EDITOR (for editor) variables (for example, in your ~/.bashrc file). Then toggle the Options -> Configuration -> Use interal edit/view option (access the top menu by pressing F9).

Panels

Alt + , - switch mc’s layout from left-right to top-bottom. Mind = blown. Useful for operating on files with long names.
Alt + t - switch the panel’s listing mode in a loop: default, brief, long, user-defined. “long” is especially useful, because it maximises one panel so that it takes full width of the window and longer filenames fit on screen.
Alt + i - synchronize the active panel with the other panel. That is, show the current directory in the other panel.
Ctrl + u - swap panels.
Alt + o - if the currently selected file is a directory, load that directory on the other panel and move the selection to the next file. If the currently selected file is not a directory, load the parent directory on the other panel and moves the selection to the next file. This is useful for quick checking the contents of a list of directories.
Ctrl + PgUp (or just left arrow, if you’ve enabled Lynx-like motion, see later) - move to the parent directory.
Alt + Shift + h - show the directory history. Might be easier to navigate than going back one entry at a time.
Alt + y - move to the previous directory in history.
Alt + u - move to the next directory in history.

Searching files

Alt + ? - shows the full Find dialog.
Alt + s or Ctrl + s - quick search mode. Start typing and the selection will move to the first matching file. Press the shortcut again to jump to another match. Use wildcards (*, ?) for easier matching.

Common actions

Ctrl + Space - calculate the size of the selected directories. Press this shortcut when the selection is on .. to calculate the size of all the directories in the current directory.
Ctrl + x s (that is press Ctrl + x, let it go and then press s) - create a symbolic link (change s to l for a hardlink). I find it very useful and intuitive - the link will, of course, be created in the other panel. You can change it’s destination and name, like with any other file operation.
Ctrl + x c - open the chmod dialog.
Ctrl + x o - open the chown dialog.

Virtual File System (VFS)

mc has a concept known as Virtual File System. Try “entering” an archive (*.tar.gz, *.rpm or even *.jar) - you’ll be able to browse the contents of the archive like a normal folder, without unpacking it first. You extract selected files from the archive by just copying them to the other panel. Bonus points: try “entering” a… *.patch file.

This concept is even more powerful when you realize that remote locations can be viewed the same way. A quick way to browse an FTP location is to just cd to it: cd ftp://mirrors.tera-byte.com/pub/gentoo (first Gentoo FTP mirror I found). You’ll be able to interact with files as you normally do. To exit this remote location, cd to a local directory. Just typing cd will suffice as it will take you to your home directory.

VFS works for SFTP and Samba shares too. Check the manpages for more information on how to specify user/pass, etc.

Useful options

Configuration
- Verbose operation and Compute totals - so that operations like copy/move have a more detailed progress dialogs.
Layout
- Equal split - uncheck to define your own ratio for panels. Maybe you prefer one panel bigger than the other? Useful especially if you keep one of the panels in tree mode (or maybe info/quick view, too).
- Uncheck Hintbar visible - one more line available, one less line of noise.
Panel options
- Show backup files and Show hidden files - I keep both enabled, as I often work with configuration files, etc.
- Lynx-like motion - mentioned above, makes left arrow go to parent directory, while the right arrow enters the directory under selection. Faster than Home, Enter, Home, Enter, etc. This options is quite smart, that is if the shell command line is not empty, the arrows work as usual and allow moving the cursor in the command line.
- File highlight -> File types is useful, as it uses a different color for example for executable files. Permissions, for me, is not that useful, but I can definitely see it’s use, for example, for sysadmins.
Appearance
- Only one option here, Skins. You can check out different skins shipped with mc - just select one from the list. I prefer gotar, because it plays well with my solarized terminal colors.
- Useful tip - set up a different skin when logged in as the root user. It’ll be easier to differentiate between root’s and normal user’s session, when you’re swapping between them (as is often the case).

Bonus assignments

Define your own listing mode (Right/Left -> Listing mode... -> User defined). Hit F1 to see available columns and options.
Play around in tree mode: Right/Left -> Tree or Command -> Directory tree.
Compare directories (Ctrl + x d)
Fill up the directory hotlist (Ctrl + \)

Well, that was a lot to take in. Of course, this list is not complete (that’s what man mc is there for), but I’ve selected the commands and functionalities that are the most useful to me. Embrace the ones you find useful, forget the rest and learn about the other ones I’ve missed!

Happy browsing!

Activities, places and the visitor pattern

Mon, 22 Sep 2014 17:01:00 +0000

If you’re writing a GWT application you are most likely following the MVP pattern. With GWT 2.1 the Activities and Places API was introduced and while it’s not strictly an MVP framework, it’s a good base for the architecture of your application.

A core component of Activities and Places is the ActivityMapper interface. Its role is simple - you get a Place and based on it an appropriate Activity should be returned. There’s one problem - you most likely will want to choose the Activity based on the type of the provided Place. The usual approach (mentioned even in the official documentation) is a long chain of if (place instanceof CustomPlace) else if (place instanceof CustomPlace2)… etc. You might have a similar if/else chain somewhere else in your application where you want to react to a PlaceChangedEvent. If you add a new Place, you have to remember to add (another…) if else in all those places.

public class AppActivityMapper implements ActivityMapper {
 @Override
 public Activity getActivity(Place place) {
 activity = null;
 if (place instanceof StartPlace) {
 return new StartActivity();
 } else if (place instanceof SearchPlace) {
 return new SearchActivity();
 } else if (place instanceof CustomerPlace) {
 return new CustomerActivity();
 }
 return null;
 }
}

There’s gotta a be a better way!

And there is: the visitor pattern.

A way of separating an algorithm from an object structure on which it operates. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures.

Sounds exactly like something we need! If the details are unclear at this point, don’t worry. It’s best to see it in action and how it fits with our needs.

Let’s say we have three custom Places in our application: StartPlace, SearchPlace and CustomerPlace. They can be with parameters/tokens or not - it doesn’t matter.

Now, we’ll define the interface of our visitor. This visitor will be able to “visit” every place that “accepts” it and invoke some place-specific method.

public interface PlaceVisitor {
 void visitStartPlace(StartPlace place);
 void visitSearchPlace(SearchPlace place);
 void visitCustomerPlace(CustomerPlace place);
}

As you can see, we have a method for each of our custom places. Every method takes a place as a parameter and returns nothing. We could return an Activity but as we’ll see further on, it limits the usage of this interface and is actually against the visitor pattern.

Now, let’s add a new base class for all of our custom places. It could be an interface, but since we always have to extend the Place class, we might as well extend it and add our method:

public abstract class AppPlace extends Place {
 public abstract void accept(PlaceVisitor visitor);
}

We only need to add one method - one that “accepts” the visitor. We leave the implementation to the specific place - that’s the whole point. We can now modify our Place to extend our AppPlace instead of just Place:

public class StartPlace extends AppPlace {
 @Override
 public void accept(PlaceVisitor visitor) {
 visitor.visitStartPlace(this);
 }
}

public class SearchPlace extends AppPlace {
 @Override
 public void accept(PlaceVisitor visitor) {
 visitor.visitSearchPlace(this);
 }
}

public class CustomerPlace extends AppPlace {
 @Override
 public void accept(PlaceVisitor visitor) {
 visitor.visitCustomerPlace(this);
 }
}

The pieces should start falling into place now - we can see above that it’s the place that decides to invoke a specific method on the visitor. This way, the visitor doesn’t know what place is accepting it, but the place can tell it: “Hey, you’re visiting a SearchPlace, act accordingly”.

We can now replace our long ActivityMapper implementation with a much simpler one:

public class AppActivityMapper implements ActivityMapper, PlaceVisitor {
 private Activity activity;

 @Override
 public Activity getActivity(Place place) {
 activity = null;
 if (place instanceof AppPlace) {
 ((AppPlace) place).accept(this);
 }
 return activity;
 }

 @Override
 public void visitStartPlace(StartPlace place) {
 activity = injector.getStartActivity();
 }

 @Override
 public void visitSearchPlace(SearchPlace place) {
 activity = injector.getSearchActivity();
 }

 @Override
 public void visitCustomerPlace(CustomerPlace place) {
 activity = injector.getCustomerActivity();
 }
}

Now, whenever we add a new Place, we make it extend AppPlace, this makes us provide the implementation for the accept method which in turn causes us to add a new method to the PlaceVisitor interface. Now, say we have a PlaceChangedEvent’s handler somewhere we can re-use the PlaceVisitor:

public class RootPresenter ... implements PlaceVisitor {

 public RootPresenter(...) {
 eventBus.addHandler(PlaceChangeEvent.TYPE, new PlaceChangeEvent.Handler() {
 @Override
 public void onPlaceChange(PlaceChangeEvent event) {
 Place place = event.getNewPlace();
 if (place instanceof AppPlace) {
 ((AppPlace) place).accept(RootPresenter.this);
 }
 }
 });
 }

 @Override
 public void visitStartPlace(StartPlace place) {
 view.getStartButton.setActive(true);
 // Or whatever else
 }

 // etc...
}

Whenever we add a new Place we have to add a new method to the PlaceVisitor which in turn flags any class that implements it with an error - now it’s impossible to miss handling a new Place somewhere in your code.

One more point worth mentioning - in the last snippet you can see that making the visit* methods return an Activity directly wouldn’t be a good idea - while it would be useful in the ActivityManager’s implementation, it would be useless in RootPresenter.

I highly recommend reading the appropriate chapter from the great Design Patterns book from the Gang of Four. The visitor pattern is a very useful one and the chapter gives examples when it’s good to use and when a different approach is better.

Happy coding!

Testing asynchronous GWT-RPC services

Thu, 28 Aug 2014 17:01:00 +0000

Continuing the theme of testing with gwtmockito, I’d like to show you a neat class that’s bundled with gwtmockito that allows for easy mocking of GWT-RPC asynchronous services.

The class I’m talking about is AsyncAnswers. It’s meant to be used with the doAnswer stubber.

Supposing we have a LoginServiceAsync class:

public interface LoginServiceAsync {
 void login(String login, String password, AsyncCallback<SomePojo> callback);
}

Assuming service is a mock for LoginServiceAsync, we could simulate a successful trip to the server with:

doAnswer(AsyncAnswers.returnSuccess(somePojoInstance)).when(service).login(eq(login), eq(password), Matchers.<AsyncCallback<SomePojo>>.any());

Similarly, we can simulate that a failure occurred:

doAnswer(AsyncAnswers.returnFailure(new LoginException("Unknown user"))).when(service).login(eq(login), eq(password), Matchers.<AsyncCallback<SomePojo>>.any());

Everything should be working, but that line is a bit too long. For starters, we can import static AsyncAnswers. But the biggest sore in the eye is the any() call. We need to explicitly set the type parameters, and for that to happen we can’t rely on static imports - we have to use the Matchers class directly. Let’s fix that by introducing a new ArgumentMatcher:

public class AnyAsyncCallback<T> extends ArgumentMatcher<AsyncCallback<T>> {
 public AnyAsyncCallback() {
 }

 @Override
 public boolean matches(Object argument) {
 return argument instanceof AsyncCallback;
 }
}

Now, to use it like any or anyCollection, put this method somewhere, like in your base test class:

protected static <T> AsyncCallback<T> anyAsyncCallback(Class<T> clazz) {
 return Matchers.argThat(new AnyAsyncCallback<T>());
}

We pass around that <T> and Class<T> for type safety - no need for casts or @SuppressWarnings. Now it looks less verbose and more to the point:

doAnswer(returnSuccess(somePojoInstance)).when(service).login(eq(login), eq(password), anyAsyncCallback(SomPojo.class));

Happy testing!

Testing gwteventbinder with gwtmockito

Wed, 27 Aug 2014 21:46:00 +0000

gwteventbinder and gwtmockito are great projects that are esential if you’re writing applications in Google Web Toolkit/GWT. So it was a surprise to me that they don’t play together well “out of the box”.

See, the problem is that gwtmockito injects it’s own (safe, not using any code that requires running a browser) mocks when it encounters GWT.create in your code. That’s very cool, but when using gwteventbinder, you need to call the bindEventHandlers method to, well, bind the event handler. And the mock, obviously, doesn’t do that.

However, there’s a solution - FakeProviders. By registering one for the EventBinder interface, it will be used for providing instances of EventBinder and its subclasses. Unfortunately, EventBinder uses a GWT Generator for it’s implementation, and to “emulate” that during our tests, we have to resort to Java Reflection.

The following implementation is inspired by comments and suggestions from an issue raised on gwteventbinder’s tracker. You can find alternative solutions there, too.

public class FakeEventBinderProvider implements FakeProvider<EventBinder<?>> {
 @Override
 public EventBinder<?> getFake(Class<?> type) {
 return (EventBinder<?>) Proxy.newProxyInstance(FakeEventBinderProvider.class.getClassLoader(), new Class<?>\[\] { type }, new InvocationHandler() {
 @Override
 public Object invoke(Object proxy, Method method, final Object\[\] args) throws Throwable {
 String methodName = method.getName();
 assert methodName.equals("bindEventHandlers");

 final List<HandlerRegistration> registrations = new LinkedList<HandlerRegistration>();
 EventBus eventBus = (EventBus) args\[1\];

 List<Method> presenterMethods = getAllMethods(args\[0\].getClass());
 for (final Method presenterMethod : presenterMethods) {
 if (presenterMethod.isAnnotationPresent(EventHandler.class)) {
 @SuppressWarnings("unchecked") // Should always be ok, since the Generator for EventBinder should do all the safe-checking 
 Class<? extends GenericEvent> eventType = (Class<? extends GenericEvent>) (presenterMethod.getParameterTypes())\[0\];
 registrations.add(eventBus.addHandler(GenericEventType.getTypeOf(eventType), new GenericEventHandler() {
 @Override
 public void handleEvent(GenericEvent event) {
 try {
 presenterMethod.setAccessible(true);
 presenterMethod.invoke(args\[0\], event);
 } catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException e) {
 throw new RuntimeException(e);
 }
 }
 }));
 }
 }

 return new HandlerRegistration() {
 @Override
 public void removeHandler() {
 for (HandlerRegistration registration : registrations) {
 registration.removeHandler();
 }
 registrations.clear();
 }
 };
 }
 });
 }

 private List<Method> getAllMethods(Class<?> type) {
 List<Method> methods = new LinkedList<Method>();
 methods.addAll(Arrays.asList(type.getDeclaredMethods()));
 if (type.getSuperclass() != null) {
 methods.addAll(getAllMethods(type.getSuperclass()));
 }
 return methods;
 }
}

It’s not as bad as it seems. When you get rid of the Java Reflection cruft, it boils down to:

Find all the methods on the presenter that are annotated with EventHandler.
Register a new handler that invokes the callback method for the event specified as it’s first argument.
Return a HandlerRegistration instance that on call to removeHandler removes all the handlers added in the previous point (this behavior is copied from the actual implementation of gwteventbinder).

You might note that I don’t do any safe-checks… Well, assuming that you’ve run your code before, using (Super)DevMode, the EventBinder’s generator already checked that your code is sane and within the requirements of gwteventbinder.

Now, all that’s left is to register this provider, for example in your @Before method:

@Before
public void setUpEventBindery() {
 GwtMockito.useProviderForType(EventBinder.class, new FakeEventBinderProvider());
}

Like I’ve already mentioned, you only need to do this for the base interface, EventBinder, since as the documentation for GwtMockito.useProviderForType says:

(..) the given provider should be used to GWT.create instances of the given type and its subclasses.

Happy testing!

Avoiding Kernel Modules When External Firmware Is Needed

Mon, 05 May 2014 21:41:00 +0000

If you’re just interested in keeping your kernel module-free and be able to watch funny cat videos on youtube, skip to the solution.

I’m an avid user of the Gentoo flavour of Linux, specifically the Hardened profile. As you can imagine, I like to think of myself as a security-aware user. With that in mind, I prefer to keep my kernel module-free (by actually disabling the ability to load kernel modules), building in every driver that I need and keeping all the rest out. The reason for this, from a security point of view, is that loading a malicious kernel module is very often [citation needed] the second step after a successful privilege escalation. I don’t need module loading – I know my hardware, it doesn’t change that often.

So imagine my disdain, when I was setting up my laptop, a (t)rusty Lenovo ThinkPad X220, and it turned out that the WIFI card (an Intel Centrino something, supported by the iwlwifi driver) needed to load external firmware (residing in /lib/firmware) upon load. Unfortunately, this did not work when the driver was built in into the kernel – I presume that /lib/firmware is simply not available when the driver loads. A possible solution would be to create an initrd image and put the firmware there… but that seemed too much hassle. So I built the driver as module and wept in the corner that night…

Fast forward to today, when I was setting up another ThinkPad (E540, for my parents) and I’ve stumbled upon the same situation – an Intel WIFI card (Intel Wireless-N 7260) that needed external firmware. But this time I’ve decided to be a man-, nay – a professional!, and tackle this problem. I mean, this the Linux Kernel, we don’t need to take this shit!

The solution was far easier than I thought, requiring no hacks or custom scripts. Didn’t need to Google even, just looked at the available options. Here are the steps:

Let’s assume you have a working WIFI card, the firmware is in /lib/firmware and is named iwlwifi-7260-8.ucode. If not, install the appropriate package from your distro’s package manager or download the firmware directly (for example, for Intel cards, from http://wireless.kernel.org/en/users/Drivers/iwlwifi).
Head on to your kernel’s sources (you do build your own kernel, right?), usually /usr/src/linux.
make menuconfig
Let’s start off with building in the driver we’ll be including the firmware for. For me, it was Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate-N (iwlwifi) (CONFIG_IWLWIFI).
Now, the options we are interested in reside in Device Drivers -> Generic Driver Options.
You probably have Userspace firmware loading support (CONFIG_FW_LOADER) enabled already (your WIFI driver should autoselect it), if not – enable it.
Under it, select the External firmware blobs to build into the kernel binary (CONFIG_EXTRA_FIRMWARE) option. As the help says: This option allows firmware to be built into the kernel for the case where the user either cannot or doesn’t want to provide it from userspace at runtime. (…) This option is a string and takes the (space-separated) names of the firmware files.
So, let’s do as the f…reaking manual tells us to do, set the value to your firmware’s filename (separating the files with spaces, if more than one). For our example, I’ve set it to iwlwifi-7260-8.ucode.
Setting this value enabled another option beneath it: Firmware blobs root directory (CONFIG_EXTRA_FIRMWARE_DIR). This is the dir that will be searched for the firmware files we’ve specified above. It defaults to the firmware directory in the kernel’s source tree. The easiest way is to point it to /lib/firmware (as I’ve done), just remember that a future kernel upgrade might mean that you’ll need to update the firmware files as well. Keeping the firmware files in the kernel’s source tree is safer, but requires you to remember (OH NOES!) to copy over (or download updated versions) every time you compile a new version of the kernel.
Save configuration, execute make -j4 (where 4 is the number of CPU cores you have, to speed things up a bit), etc.
Reboot and check in dmesg that the firmware has indeed been successfully loaded.
Bonus points: disable the module loading altogether in Enable loadable module support (CONFIG_MODULES).

Hope this helped someone and happy hacking!

Posts on Igor Klimer's personal site

Migrating from Create React App to Vite

Why migrate?

Simplified migration steps

Gotchas

Workers

Day.js dynamic locale loading

Performance comparison

Page load

Lighthouse metrics

Security audit

Dependencies

Conclusion

Use Midnight Commander like a pro

Hold your horses

Selecting files

Accessing the shell

Internal viewer (F3) and editor (F4)

Panels

Searching files

Common actions

Virtual File System (VFS)

Useful options

Bonus assignments

Activities, places and the visitor pattern

Testing asynchronous GWT-RPC services

Testing gwteventbinder with gwtmockito

Avoiding Kernel Modules When External Firmware Is Needed

Internal viewer (`F3`) and editor (`F4`)