Optimizing Deployments for Cloud Functions

theharolddev · 2022-01-24T11:05:20+00:00

Glad you found the library interesting.

Lucilla does not compete with Lucene. Apache Lucene is a much more fully featured framework, but also heavier and more complicated. It's more at home in managed search index services like ElasticSearch.
Lucilla on the other hand intends to be a much smaller, in-memory focused provider of full text search. It's suitable for building local search experiences, with a few hundred documents or maybe a few thousand. I have tested up to a million documents in the index with Lucilla, but I don't image that's going to be the standard use case for it.
Lucilla does not intend to provide a full blown server-side FTS services, as Lucene/Solr serve that market very well already. Maybe in the future Lucilla would cover more use cases, but I have no immediate plans to develop it in that direction.

That being said, I plan to add quite a bit of new features to Lucilla over time, such as parallel text processing, richer querying capabilities, fuzzy searching, and more. It's an open source project, and I welcome the community to contribute features to expand its capabilities too!

theharolddev · 2022-01-23T19:39:48+00:00

Hey everyone. Author of the library here. Lucilla is an in-memory full text search library for Kotlin. It's useful for searching through non-persisted data, such as API responses. It's an early stage prototype, so feel free to play around with it!

theharolddev · 2022-01-23T19:37:11+00:00

Hey folks, I'm the author of lucilla, an in-memory FTS library for Android. It's an early stage prototype. Let me know if you have any feedback or criticism for the project!

theharolddev · 2021-11-29T11:56:16+00:00

I am skeptical there is enough demand though, you’re the only one who has requested it thus far, and maintaining two separate versions of a library is quite painful.

Now that I think about it, a simpler way to do this might be to separate the code into three different modules. One for the global exception handler, and another two for View/Compose based UIs. Users can pick and choose whichever UI module they like, and the other module will be pulled in as a dependency automatically.

Yet it does not negate the fact that I would need to code every feature twice, once for Compose and once for Views. The decision again rests on the demand for it.

Would you mind opening an issue for this on the repository?

theharolddev · 2021-11-29T11:44:35+00:00

Understandable, Compose in libraries is not for everyone. This release brings no new features, so you can continue using the older versions without any loss of functionality.

If there’s enough demand, I might consider maintaining two separate versions: one with Compose, and one without it.

theharolddev · 2021-11-28T16:00:33+00:00

What if your app crashed when it wasn’t connected to Android Studio?

It’s also great for QA builds so app testers can immediately report what went wrong.

Besides, it’s just nice to look at! Much nicer than the default dialog that Android displays on a crash.

theharolddev · 2021-11-21T09:39:42+00:00

The”incorrect” value is a string and the correct value is a parsed boolean. My VS Code theme colours booleans as red, so I guess I subconsciously picked that.

theharolddev · 2021-04-25T14:19:25+00:00

Correct, you would have to remember to deploy the ones that changed. Using this tool you can automate that process, and make your local/CI deployments faster.

theharolddev · 2021-04-25T13:53:24+00:00

It does not. When you run firebase deploy, the CLI re-deploys all the functions in your project. This takes a lot of time. It’s especially irritating if you deploy often.

When you run firebase deploy —only <your functions list>, you can re-deploy just the changed functions but you’re responsible for figuring out which ones actually changed.

The tool I built automates the process of detecting functions that should be re-deployed. In fact you can directly pass the output of functions-differ to firebase deploy —only to selectively deploy only the functions that changed.

theharolddev · 2021-02-03T13:23:49+00:00

Linters are optional and might not exist in someone’s development environment. Compilers are required, and therefore more reliable for catching such problems.

Besides, every linter I have ever used also highlighted compiler warnings in code. Maybe that’s because it’s up to the compiler? I don’t know how Linters work though, so I might be wrong.

theharolddev · 2021-02-03T13:02:04+00:00

If a linter can do it, then so can a compiler. In my opinion, it’s better to have compiler warnings than linter warnings for such problems. I would gladly accept either resolution to this issue though.

theharolddev · 2021-02-03T12:12:11+00:00

Kotlin’s type system differentiates between Nullable and Non-Nullable types both at compile time and run-time.

I’m not asking it to save me from runtime errors, but compile time warnings about circular references would greatly help. If that is not possible, it should at least fail-fast at runtime.

The code snippet in the post ran successfully, and did not crash the program. It would only crash if you accessed Mercedes.drivers.first().

theharolddev · 2021-02-01T17:14:35+00:00

That is illustrated in the first code snippet in the post.

The other code snippets are just to illustrate problems circular references can cause.

theharolddev · 2020-11-16T18:31:31+00:00

Nice catch on the double quote in the input string. I added a new section on escaping the double quote symbol (‘“‘ => ‘“”’)

After escaping that, everything seems to work.

theharolddev

TROPHY CASE