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.
Use Midnight Commander like a pro
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?
Activities, places and the visitor pattern
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.
Testing asynchronous GWT-RPC services
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:
Testing gwteventbinder with gwtmockito
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.
Avoiding Kernel Modules When External Firmware Is Needed
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.