Untitled Publication

How to massively rename directories in a project

Marco Romano — Tue, 14 Mar 2023 13:09:26 GMT

I recently had to change the package name of a project I'm working on but somehow the IDE didn't manage to adjust the name of the directories accordingly.

Turns out there's a command line utility called rename that can be helpful in such situations.

You can install it with your favorite package manager e.g.

brew install rename

And then you can use it as such:

find ./ -type d -name oldname -execdir rename 's/oldname/newname/g' '{}' \+;

This will use the find command to find all subdirectories of the current directory named "oldname" and then will execute the rename command to rename each of them from "oldname" to "newname".

Approaching your first remote job

Marco Romano — Mon, 09 Mar 2020 15:04:35 GMT

A lot of contract and employment considerations you might want to think about before starting to look for a remote job.

Photo by Susanna Marsiglia on Unsplash

Acknowledgments: If you can read this article it’s because Stefano Magni has been more than supportive from its inception to its publication. Kudos to him!

Chances are if you’re reading this you might already be working in software development or be interested in working in the field. Software is great and it’s for sure a sector of the world’s economy that is growing and will keep growing for years to come. If you’re like me and come from a small town in the countryside you may have already come to peace with the fact that if you want such a job you’ll have to say goodbye to your nice little village and relocate.

Software companies tend to build a handful of very big offices either in big cities (e.g. New York, Seattle) or in specific geographical areas (e.g. Silicon Valley), why? Perhaps for efficiency reasons: it lends to economies of scale to provide services for a greater number of employees out of a single location rather than having to provide the same services spread out over many smaller locations, and we all know that the biggest and most famous SW employers tend to offer a lot of perks among these services (did someone say food?).

So people are flocking to these well known locations in order to get a hold of a SW job and this doesn’t come without issues.

Thankfully the world is not a place where things typically stand still so change is coming even in this particular field. Thanks to both modern communication technologies and the increasing demand for software, job offers that don’t require the candidate to relocate are becoming a reality.

What is remote working?

The term pretty much speaks for itself: These are jobs in which the employee can work from a location of his/her own choice without having to relocate to the company’s office location.

Oh cool, wait but what? Of course there are caveats, keep on reading.

Which companies tend to offer remote positions?

Neither Google, Amazon nor {name your favorite big tech company} is going to hire you remotely, at least for the moment: these companies don’t generally offer remote jobs nowadays. This doesn’t mean your hopes are lost, but only that you’ll have to set your aim somewhere else. There are plenty of smaller companies and startups that are driving the remote job market. At least now you know where not to look.

Can I be legally employed?

This pretty much boils down to the countries the employee and employer are located in.

Same country If the employer has a legal entity in the same country you reside in then it is highly likely that you can be hired as a regular full time employee as per your country’s job laws: your rights and obligations will be similar to those of any other employee in that country.

Different countries If you don’t reside in the same country as your prospective employer it may be very difficult or not possible at all to get hired as an employee. These are some of the possible scenarios:

Through an intermediary Some companies will hire you remotely across different countries with the help of a 3rd party. The 3rd party might often be a staffing or HR consulting firm which already has a legal entity in your country and with which you will sign the employment contract. This will enable you to be legally employed with the only caveat that technically the actual employer will be the 3rd party company.
As a contractor This means you’ll set up your own legal entity to work as a self-employed person or freelance in your country and your prospective employer will hire you as a contractor. This does not mean you will not feel like a regular employee, after all it is in the interest of your employer to make you feel part of the team, but it will certainly mean that: 1) You’ll get paid in a different way (i.e. sending out invoices instead of receiving a payslip). 2) You’ll have to take care of your own taxes and social security. This may be more or less of a burden depending on the tax laws of your country. 3) Any regulations which may be protecting employees in your country won’t apply to you because you’re technically not an employee.

This is a very important aspect: if you don’t feel comfortable working as a contractor and don’t live in the same country as your potential employer you might as well as give up looking for a remote job right now.

Hunting for a remote job

Set your expectations.

Don’t rush it

These things can take quite some time: allow at least 6 months to look for a remote job as the bare minimum, for many people this can easily go up to 1 or 2 years.

Internships or junior roles

Remote working is still in its infancy so it is likely that your prospective employer won’t be yet set up to train junior employees or interns remotely. This means that most often remote positions will be reserved to candidates with medium to senior level experience. In other words: the employer will want to somehow ensure that the candidate can carry out the work as autonomously as possible and without relying on constant help: most often offering positions only for people with enough past experience is a way of achieving this.

Multiple applications

Applying at Google or Amazon can be regarded as a “safe bet” in the sense that if any of those companies will hand you an offer at the end of the interview process you’ll most likely accept it without pondering too much over it.

Companies offering remote jobs often don’t have the same level of fame and notoriety of the ones above so chances are you won’t know much about the company you will be applying to. So please hedge your bets and apply to more than one company at the same time: it will speed up your job seeking process, let you gain more experience out of the additional chats and interviews and broaden your choices when it comes to picking which offer to accept. All of which will translate in increased chances of not having to regret your employer choice.

Where to apply or send your CV?

Non-exhaustive list of websites (not in order of relevance)

Useful posts

Non-exhaustive list of remote-friendly companies

https://twitter.com/chris_herd/status/1202962206226292736?s=03

Don’t forget you should also google for jobs yourself.

Learn about your prospective employer

Your prospective employer is trying to learn about you through its recruitment process: you should do the same (from a business, not a personal, perspective). You should try to assess the company you’re interviewing with to make sure the actual job and your expectation of it won’t be too far apart.

Your application and interview processes can vary greatly depending on the company you’re applying to. Here are some factors that can contribute to such differences when it comes to company size and experience:

Well established, medium/big size company

Bigger companies usually have dedicated HR and recruiting staff which most likely will have already put in place well defined processes to handle remote job applications and their applicants.

Because of this, the employer will usually take a “leading” role in the application process, guiding you from the early phases of the application through the various interviews and eventually to an offer.

You’ll most likely have to go through one or more phone interviews or video calls and, if successful, will be “flown in” to the company’s office for some more interviews on-site.

Young, small size company or startup

These companies usually don’t have full-time hiring staff, so don’t expect particularly structured hiring processes. Most likely you’ll get to speak with your prospective teammates and CEO since the early stages. The whole process may happen over video call and you may not get to physically meet your potential colleagues up until you’ve actually been hired.

Remote first or remote “sometimes”?

Regardless of what a company may tell you about their culture being “remote first” this may not always hold true.

If the company culture does not really embrace remote working your dream job can quickly turn into a lonely nightmare.

A good “remote first” indicator is represented by the number of remote versus regular employees at the company (a very important question to ask during the hiring process).

Companies whose majority of employees are non-remote might unwittingly favor a non-remote friendly work style which might include:

Having a lot of impromptu meetings in which remote employees are left out.
Sharing work related information during water cooler talk or during lunch time.
Being used to very quick interaction cycles which usually involve frequent “shoulder tapping” and interruptions.

It’s hard to predict if this will be the case, but knowing beforehand that at least about half of the workforce is remote can make it a bit more likely that the company as a whole will think remote first.

Getting through the interviews

It’s hard to predict what a job application will look like, but most often it is a multi step process which might involve phone calls, video conferences, assignments and sometimes in-person meetings.

Please note the phases described hereafter might not always be present in all application processes and/or might come in a different order.

Screening phase

This is the first contact from the prospective employer after you’ve sent them your CV or filled their online job application form.

It happens usually via email and its aim is to schedule an introductory phone or video call.

This very first call might not always be technical but it is usually meant as a form of assessment to make sure the applicant is legit. In other words, it is meant to quickly reject any persons who might have applied by mistake or that might be blatantly unfit for the job.

Remote assignments

If the screening phase is successful you might get a request to complete an assignment which could be of various types: Either an online test or a timed coding challenge or just a request to develop a piece of code and deliver it after a few days.

Technical Interviews

After your assignment is complete and has been positively reviewed you usually get a request for a technical interview. This means that you will talk most likely with people who are doing the same or a similar job to the one you are applying for. Expect a lot of technical questions here.

HR/Management Interview

This phase might happen at any time in the process, it will be the phase where you will meet non technical people from the company and during which you will talk about contracts, salary and perks.

Job contract bargaining

After passing all phases of the interviews if you’re successful you’ll be extended an offer which at a certain point will get written into a job contract.

What comes after mostly depends if you’re getting hired as an employee or as a contractor (please remember the “Can I be legally employed” section).

As an employee

There’s usually not much room for bargaining besides the amount of pay (gross yearly amount) in this case.

You’ll most likely have to sign your country’s standard job contract and will get whatever social security benefits and whatever amount of vacation days the standard contract offers (which can differ greatly from country to country).

As a contractor

Things here get a bit more complicated: since there is no standard employment contract when working as a contractor, you’ll have to iron out all the things that are usually taken for granted when employed, these may comprise:

Salary amount
Salary currency Your employer might be in a country with a different currency than yours in this case you should carefully negotiate who should carry the burden of the exchange rate.
Vacation days All countries have different laws and in some vacation days are included in an employment contract, in others they are not. You should not take for granted that your contract will or will not include vacation days. You should negotiate whatever suits you best.
Sick days There is no social security coverage for contractors when sick. Most employers won’t usually bother if you need to take a few days off because you’re sick. Of course you shouldn’t cheat or you’ll break the trust in the employee/employer relationship.
Bank holidays These are also up for negotiation. Some companies grant the bank holidays of the employee’s country, some prefer to have all employees adhering to the headquarter’s country bank holidays. Some won’t even grant bank holidays to contractors: YMMV.
Leaving notice This is your safeguard in case something goes awry. Leaving notice is the advance notice if one of the parties chooses to end the contract, this depends on how long on average it might take for you to find another job.
Work hardware In most cases the employer will provide the necessary hardware (i.e. a laptop), but if you already have the right gear you might “trade” the cost of the hardware for some other benefit.
Conferences Many companies have a budget for conferences, it might be wise to check if it also applies to remote employees.
Business trips Sooner or later you’ll have to travel to the company’s headquarters or to some company meeting. Making sure beforehand that such trips will be paid for by the company can avoid bad surprises when the need to travel arises.
Other perks There can be conutless other benefits that your prospective employer might be willing to offer you (or might not :) ). As with everything we’ve discussed so far these are all part of the bargaining process: it’s up to you if you want to ask your employer to pay for a certain benefit or if you prefer to factor this cost in the main salary upfront.

About the author

My adventure with remote working started around 2 years ago. I live in the countryside of Italy and used to work in the city of Milan: a journey which took away almost 2 hours of my life every morning and another 2 hours every evening.

My previous employers used to allow work from home once in a while, but no more than a day every week.

I tend to be very prone to distractions so my performance suffers in an office environment, especially one in which continous interruptions by collegaues are more likely to be the norm rather than the exception.

Pretty soon the single day I could spend working at home started becoming the dream of what I wanted my work life to be.

Being able to start coding in the morning and continue all the way through the afternoon was something very rarely I managed to experience when at the office.

So when the long commute to work started to feel unbearable I went looking for alternatives.

The search

At the time the vast majority of job offers I could find didn’t allow remote work and were either still based in Milan or required relocation.

Since relocation wasn’t an option due to family matters, I couldn’t stand the idea of having to stick to that long commute so one day while on Stack Overflow I noticed something uncommon in the usual job postings that appear in the right column: one of them was bearing a “REMOTE” badge… Boom! That was the spark that started everything. I simply had to factor in the “remote” keyword while looking for job posts and all of a sudden different kinds of job offers started surfacing from my searches.

Things didn’t go as quick as I hoped though: I had to exclude almost all of the offers from American companies because they required living in an American timezone. Remote work in Europe wasn’t that popular by then so it took several months before I could find some applicable open positions, apply to them and go through any interviews.

The effort has been rewarded though, I eventually found a company which looked like a very good match for my skills, goals and work culture and which has now become my current employer.

The good

So far it’s been almost 2 years since I’ve been working fully remotely and I’m very happy with the choice; the tools we use for remote work make the experience almost seamless and, apart from team building and other social moments, there hasn’t been a single time in which I felt the need of having to physically be at the company headquarters.

Even though I sometimes miss the social environment of the office, being able to reclaim 4 hours of commuting time every day has been priceless for me: I now have time to meet with friends and to stay with my loved ones and overall my life is better balanced now than it was before.

The not so good

So far the biggest downsides I could notice mainly boil down to 2 areas:

Fitness Not all the people feel the need to excercise, I’m one of those. Remote working ended up making me enjoy sedentary life a bit too much so I eventually had to acknowledge that my body was suffering from a lack of fitness and had to start going to the gym.
Serendipitous interaction Believe it or not but living in a small town where the chance of randomly bumping into another software engineer is close to zero might make you feel “professionally lonely” at times. Unfortunately I didn’t find a definitive solution to this yet, but I’ll try to keep you posted when I will!

RxJava error handling: OnErrorNotImplementedException vs UndeliverableException

Marco Romano — Thu, 01 Nov 2018 17:29:39 GMT

I recently spent some time digging into RxJava’s error handling facilities and realized that throwables forwarded to RxJavaPlugins.setErrorHandler() are sometimes wrapped in OnErrorNotImplementedException and sometimes in UndeliverableException . I couldn’t easily figure out why and when so I drafted a piece of code that I hope might help others shed some light on the matter.

Exceptions can occur in many places in an RxJava chain but for this specific article we will cover three particular situations:

1) Upstream exceptions

Exceptions coming from upstream (i.e. from the source we are hooking up to) are forwarded to the subscriber’s onError() if present, or wrapped in OnErrorNotImplementedException and sent to RxJavaPlugins.setErrorHandler() if not present.

2) Midstream exceptions

I’m using the term ‘midstream’ here (which does not belong to RxJava’s vocabulary) solely for lack of a better term.

Exceptions thrown inside a subscriber’s onNext() are forwarded to their relative onError() if present, or wrapped in OnErrorNotImplementedException and sent to RxJavaPlugins.setErrorHandler() if not present.

3) Downstream exceptions

Exceptions thrown inside a subscriber’s onComplete() or onSuccess() are not forwarded to their relative onError() even if present, they are instead wrapped in UndeliverableException and sent to RxJavaPlugins.setErrorHandler() . Exceptions thrown inside onError() follow the same path.

Why is 3) special?

While 1) and 2) seem to be pretty straightforward why is 3) different? As mentioned in this enlightening RxJava issue, these exceptions cannot be forwarded to onError() because onError() onComplete() and onSuccess() are terminal events of a flow and thereby must always be a flow’s last emission. Since the exception itself originated during a terminal event, forwarding it to onError() would imply emitting an onError event right after an onSuccess event thereby violating the definition of terminal event (for further info check out Rx’s Observable Contract).

Caveat emptor!

This can get especially tricky when mixing Observables/Flowables and Singles/Maybes/Completables because the formers do emit onNext events, while the latters do not.

Let’s say you were processing an Observable’s events inside an onNext and handling relative errors in an onError : during a refactoring that Observable is changed into a Single, and so you “move” the event processing logic from onNext to onSuccess while keeping onError as is. This triggers a problem: If the event processing logic throws an Exception, it won’t be forwarded toonError anymore but is instead wrapped in UndeliverableException and sent to RxJavaPlugins.setErrorHandler() .

Too much talking, show me the code!

Here you go and thanks for reading!

package net.kjulio.rx.test

import io.reactivex.Completable
import io.reactivex.Flowable
import io.reactivex.Maybe
import io.reactivex.Observable
import io.reactivex.Single
import io.reactivex.exceptions.OnErrorNotImplementedException
import io.reactivex.exceptions.UndeliverableException
import io.reactivex.functions.Consumer
import io.reactivex.plugins.RxJavaPlugins
import org.junit.Assert
import org.junit.Test

class RxErrorDeliveryTest {

    @Test
    fun upstreamErrorsAreRoutedToGlobalHandlerWhenOnErrorIsMissing() {
        val list = mutableListOf()
        RxJavaPlugins.setErrorHandler { list.add(it) }

        Flowable.error(RuntimeException()).subscribe()
        Observable.error(RuntimeException()).subscribe()
        Single.error(RuntimeException()).subscribe()
        Maybe.error(RuntimeException()).subscribe()
        Completable.error(RuntimeException()).subscribe()

        Assert.assertEquals(5, list.size)
        list.forEach {
            Assert.assertTrue(it is OnErrorNotImplementedException)
            Assert.assertTrue(it.cause is RuntimeException)
        }
    }

    @Test
    fun upstreamErrorsAreNotRoutedToGlobalHandlerWhenOnErrorIsPresent() {
        val list = mutableListOf()
        RxJavaPlugins.setErrorHandler { list.add(it) }

        Flowable.error(RuntimeException()).subscribe({}, {})
        Observable.error(RuntimeException()).subscribe({}, {})
        Single.error(RuntimeException()).subscribe({}, {})
        Maybe.error(RuntimeException()).subscribe({}, {})
        Completable.error(RuntimeException()).subscribe({}, {})

        Assert.assertEquals(0, list.size)
    }

    @Test
    fun downstreamErrorsAreAlwaysRoutedToGlobalHandlerRegardlessOfOnErrorPresence() {
        // They couldn't be routed to onError (when present) because the stream has already
        // completed and by contract invoking onError would represent another emission.

        val list = mutableListOf()
        RxJavaPlugins.setErrorHandler { list.add(it) }

        Single.just("").subscribe(Consumer { throw RuntimeException() })
        Maybe.just("").subscribe { throw RuntimeException() }
        Completable.complete().subscribe { throw RuntimeException() }

        Flowable.just("").subscribe({}, {}, { throw RuntimeException() })
        Observable.just("").subscribe({}, {}, { throw RuntimeException() })
        Single.just("").subscribe({ throw RuntimeException() }, {})
        Maybe.just("").subscribe({ throw RuntimeException() }, {})
        Completable.complete().subscribe({ throw RuntimeException() }, {})

        Assert.assertEquals(8, list.size)
        list.forEach {
            Assert.assertTrue(it is UndeliverableException)
            Assert.assertTrue(it.cause is RuntimeException)
        }
    }

    @Test
    fun midstreamErrorsAreRoutedToGlobalHandlerWhenOnErrorIsMissing() {
        val list = mutableListOf()
        RxJavaPlugins.setErrorHandler { list.add(it) }

        Flowable.just("").subscribe { throw RuntimeException() }
        Observable.just("").subscribe { throw RuntimeException() }

        Assert.assertEquals(2, list.size)
        list.forEach {
            Assert.assertTrue(it is OnErrorNotImplementedException)
            Assert.assertTrue(it.cause is RuntimeException)
        }
    }

    @Test
    fun midstreamErrorsAreNotRoutedToGlobalHandlerWhenOnErrorIsPresent() {
        val list = mutableListOf()
        RxJavaPlugins.setErrorHandler { list.add(it) }

        Flowable.just("").subscribe({ throw RuntimeException() }, {})
        Observable.just("").subscribe({ throw RuntimeException() }, {})

        Assert.assertEquals(0, list.size)
    }
}

Writing TypeScript on a laptop? This might improve your battery life.

Marco Romano — Wed, 04 Jan 2017 21:03:07 GMT

Two things happened recently:

My laptop’s battery was draining out too fast.
I began learning TypeScript.

I’m using tsc (TypeScript’s compiler) in watch mode which is very convenient to trigger automatic transpilation while developing.

But here’s what happens:

Node (which the TypeScript compiler runs on) is eating 8% of CPU cycles just while sitting down waiting for file changes. WOW.

A quick digging around pointed me to this link: https://github.com/Microsoft/TypeScript/pull/8196/

Apparently tsc reverted to a polling approach to watch for file changes which appears to be quite resource intensive. They made this choice because the non-polling approach used previously turned out to be slow at detecting file changes in many cases.

But not all hope is lost!

Luckily the non-polling file watcher is still in the code and can be enabled by setting this environment variable: TSC_NONPOLLING_WATCHER="1" .

So now watch this:

Now it is like it should be: No file changes, no CPU usage.

Up until now I did not notice any laziness at detecting file changes on a 2016 MacBook Pro 13" running mac OS 10.12.2 and the battery life got a big improvement since then.

Hope this helps.

Marco

Working around an infamous macOS Sierra Dock bug

Marco Romano — Sun, 01 Jan 2017 17:08:43 GMT

Lately I’m running more and more into an infamous macOS bug whereas the Dock.app somehow hangs leaving the macOS GUI in a semi-stuck state in which, depending on the odds, you might find yourself unable to:

Launch Mission Control (either via keyboard or hot corner).
Launch any app from the dock (sometimes clicking and holding on a dock icon does bring up the contextual menu though the menu itself doesn’t react to any clicks whatsoever).
Launch Spotlight (either via keyboard shortcut or by clicking its icon in the menu bar).
Force quit any app (pressing CMD-ALT-ESC will bring up the force quit window though it doesn’t react to any clicks whatsoever).
Something else: YMMV.

The only symptom that happens 100% of the times is the inability to launch Mission Control, the others happen randomly.

When does this happen?

Though I can’t seem to reliably reproduce the bug, it usually happens right after dragging a recently downloaded file from the Downloads stack in the dock to the desktop.

Trivial workaround

If the dock icons are still clickable and/or Spotlight can still be launched the workaround is trivial:

Launch the Terminal app from either Spotlight or from a Dock shortcut (if you have one) and run the killall Dock command.

A little less than trivial workaround

If the GUI is stuck so much you can’t launch the Terminal app in any way or you can’t type any command in it because the keyboard input is stuck too then your only chance is to force shutdown your Mac and start over.

But…

You can be proactive and prepare a better workaround that should work most of the times:

Open the Script Editor application and create a new AppleScript with the following line inside: do shell script "killall Dock"

Save it in the Applications folder with file format Application and file name Kill Dock.app

Use Siri to launch this newly created AppleScript Application whenever your Dock gets stuck. As strange as it may seem, Siri stays fully operational after the Dock hangs, so just hit the Siri key on the keyboard (or Touch Bar) and tell Siri: “open Kill Dock”.

Voila: Siri will launch the AppleScript command and reset your dock for you.

Hope this helps.

Update 2017–02–24:

It seems that the macOS Sierra 10.12.3 update fixed this bug. A workaround is no longer needed therefore.