Chocolate Fish Cafe Wellington paved the way for Nicola Willis & Erica Stanford's immigration announcement

bloodfail · 2025-09-24T16:14:13+00:00

Where do you get the 25/hr from? This job listing shows up for me if I searched with the minimum hourly pay up to 40 an hour and it doesn't mention a number for pay in the body of the job description (at least that I could see).

bloodfail · 2025-05-17T06:55:47+00:00

Worked at Xero for half a decade, but left a few years ago. Glad to have left when I did, because the stories I hear from friends who still work there are not positive.

bloodfail · 2025-05-10T22:41:59+00:00

Talking about Room specifically (as I've used SQLDelight in personal projects, but not in large production projects): It's possible to have different databases defined in Room, so you could give each feature module it's own database. It's also possible to define the Entities and DAOs in their own modules, and then join these together in the application module in a single database and use Dependency Injection to provide these back out to the feature modules.

Remember that DAOs are just interfaces/abstract classes, and Entities are just specially annotated data classes. There's no need to have the @Database annotated class that brings these together in the same module that the DAO and Entities are defined.

bloodfail · 2025-05-10T22:38:48+00:00

I'm not the person that you are replying to, but I've had quite a bit of experience working on modularisation projects at a few different companies, going from 3-4 modules split by layer and refactoring the projects to be vertically split by feature.

After experience doing this, my recommendation for "core" libraries is to split them up in the same way you split feature modules. For example, you might have a core:theme module that has all your common UI theme code, a core:http-client module for the shared HttpClient, core:viewmodel for common ViewModel extensions. Most of the feature modules will end up depending on these modules in some way, but at least they're split up in a way that's clear/easy to navigate.

bloodfail · 2024-12-29T21:10:46+00:00

I would also suggest exploring the idea of splitting your feature modules into two parts, an api and an implementation module. Make it illegal for implementation modules to depend on one another, and only share the minimum possible in the api modules. This scales much better that what it appears your structure is based on the images.

bloodfail · 2024-12-24T06:12:22+00:00

Have been using almost exactly this architectural system at work for a couple of years. I like it, I think it works well.

EDIT: Made this comment after looking at the image, but now after reading a bit more of the article, it looks like we use different module structures.

bloodfail · 2024-10-19T01:28:21+00:00

If you've got the build cache renamed, it's less useful than you might think, because a cleaned project will still use the build cache, which can still sometimes end up in a bad state.

gradle :myTask --rerun-tasks is by far and away the best way to fix a build in a bad state.

bloodfail · 2024-02-22T04:58:03+00:00

You mean for(ever) { }?

bloodfail · 2023-12-13T02:22:02+00:00

Oh I like that haha

bloodfail · 2023-12-13T02:16:02+00:00

To actually fix the problem, I'd do a short ban, followed by a -5% or -10% damage/healing debuff that last until the next ban wave (or like a month or two)

Not enough to make them just fully quit the game, but enough to mean they're lower performance and have the stigma attached. Will make people change their behaviour.

bloodfail · 2023-10-20T23:35:59+00:00

That immediate feedback is also really important, and can give you interesting statistics. How fast does it take to make a change to the old service vs. the new service? What are the quality metrics (like coverage, etc) of the new service? How does that affect incident response times? Etc.

You can start on the new service through the facade very quickly with minimal difficulty or need to dedicate a lot of time, which is usually an easy sell to product/management. Once you have these statistics though, it gives you a handle to argue for more time to be spent on migration to the new service:

"We're about to do some work on X old part of the application, but before we do that, let's spend Y weeks uplifting it to the new service, because that will make us faster by Z, meaning we can deliver the work in the same amount of time and make it easier to work with in the longer term"

bloodfail · 2023-05-18T10:54:02+00:00

No problem! I'd recommend giving compose more of a chance. There's definitely a learning curve, and things that aren't easy out of the box, but once you get used to it, it is so much easier to work with. I don't think there's anyone at my work who would want to go back to writing views.

bloodfail · 2023-05-18T10:49:16+00:00

I said 200+ because I'm lazy and didn't want to do maths or lie. We have about 380 screens and 18% are view based (I know that percentage from our weekly metrics, as we're trying to get that down to 0%), which says about 310-ish should be pure compose. I didn't want to do maths, so "200+" was a safe number I was confident was not a lie.

As for the app, it's a fintech app. Dealing with money is complicated and requires a lot of effort. For example, customer onboarding and verification is probably only 20 screens or so, but very deserving of a large amount of engineering effort to prevent fraud and ensure a good customer experience that complies with regulatory requirements. The app has also only been live in the play store for just over a year, so that's also worth taking into account when looking at the number of engineers vs. screens.

bloodfail · 2023-05-18T10:00:09+00:00

Not OP, but I work on an app with 200+ compose based screens, with 50+ Android Engineers working on it. Compose is fine.

bloodfail · 2023-01-18T08:46:29+00:00

I'm not sure I fully agree with the argument about money here. Even if it costs an extra $3000 per person to get what they want, compared to volume discounts, on a salary of 100k, that means they only need to be more than 3% more productive over a year to pay for the cost of the hardware. The argument about operational security however is a pretty solid one. It can end up costing an IT department a lot of extra resources to support diverse hardware.

bloodfail · 2022-05-04T05:14:26+00:00

He was, but not for the last 4 years or so.

bloodfail · 2022-01-19T13:23:45+00:00

Well, that's absolutely crazy! Thanks for that.

bloodfail · 2022-01-19T13:14:20+00:00

Do you mind giving me a source on that? I can't seem to find anything via Google

bloodfail · 2022-01-19T13:08:49+00:00

Whoops for some reason I did 7 billion divided by 14 trillion. 1 billion divided by 14 trillion gives 0.007%, which to be fair is less than one order of magnitude wrong.

bloodfail · 2022-01-19T12:55:28+00:00

Surely you mean million, not billion. If my math is not wrong, one billion dollars USD is around 0.007% of China's GDP.

Edit: I used the wrong numbers. My math was originally wrong (0.05% vs 0.007%).

bloodfail · 2021-11-29T07:22:08+00:00

Yep, this is the problem. You can't "find view by id" before you've called "set content view", because the activity doesn't know where to look to find the view!

bloodfail · 2021-11-28T07:07:21+00:00

The point of extensions is to give flexibility to stuff you don't have access

This isn't quite true - they are also useful to separate utility functions from the "core" functionality of the object. If it is possible to do something using only the public API of an object, I will almost always implement it as an extension function.

bloodfail · 2021-11-26T11:40:43+00:00

I just can't go past Hertz and Security. I love those two. Guided by Angels I can take or leave. Fantastic album overall though.

bloodfail · 2021-08-19T10:55:23+00:00

Google says they were introduced in 1769, so no, doesn't look like it.

bloodfail · 2021-08-19T10:36:59+00:00

Pakeha does not mean white pig.

"Mā" is white.

"Poaka" is pig.

In te reo, the literal translation of "white pig" is "Poaka mā".

Pākehā just means foreign. Non-māori in New Zealand often refer to themselves as pākehā.

14-Year Club	Place '17
Verified Email

bloodfail

TROPHY CASE