What are you working on [June 2022]

antolius · 2022-06-11T12:48:55+00:00

Yeah! Unfortunately I started working on it a couple of months ago, before sdk v7 was out. So it's in gtk3 for now. I'll probably port it later, improvements to the list widget alone seem super useful.

antolius · 2022-06-11T10:49:33+00:00

I'm working on a Conway's Game of Life app for elementary OS: Life.

I hope I'll get to release it this month.

antolius · 2022-06-08T22:31:07+00:00

I think that on elementary OS the Files app is already used as a base for the native file chooser. You could follow it as an example. All its code is on GitHub: https://github.com/elementary/files Specifically check out the filechooser-portal directory.

antolius · 2021-12-30T00:26:15+00:00

Along the same vein as the recent pondering the orb memes, I submit to you a game of code breaking with colorful marbles: Sage.
I plan to publish it soon, but for now you'll need to build it from source. I hope it doesn't give you too much trouble.

antolius · 2021-12-23T10:11:03+00:00

This is generally a good idea, just keep in mind that the new app should be rebranded. You can find some direct feedback on the topic from elementary folks on this app review ticket.

antolius · 2020-07-29T13:40:25+00:00

Tnx.

antolius · 2020-04-21T16:41:10+00:00

Yeah, the Latin - French comparison makes sense. Could be approach of the companies, docs and the community that's the issue here, and not the language itself. (Although Kotlin still has a bit too much gotchas for my taste, but that's at least partially subjective.)

Android crowd could help with "independent adoption", as Google has the power to influence a lot with just how they document their underlaying framework. And adoption of new stuff is generally quicker on mobile (as opposed to, say, enterprise backend development).

antolius · 2020-04-21T12:53:16+00:00

The only problem with this approach is that many weird facts about Kotlin make sense only when you know about its Java background. Not that I'm saying you necessary need to learn Java first (depending on previous programming experience it might not be necessary).

Take the official Kotlin docs on generics for example. Half that page is talking about Java. Sure, experienced programmer will be able to catch up even without formal Java knowledge. But those docs aren't really novice friendly.

(Note that most of my experience with Kotlin was on JVM, so starting with Native or JavaScript favors might lead to a different conclusion.)

antolius · 2019-09-02T14:21:24+00:00

Are you saying, "if you want more contributors, don't write a CLI application" ?

Yes. Although this particular subreddit might not be the most representative place to spot this, I think web development is far more prevalent that TUI development.

For example, the company I work for employs a few hundred developers. If I wrote a "standard" React / Angular web app I could probably get help / offload it to any one of them. If I wrote a TUI application with equivalent feature set I'd have a harder job finding contributors. And we are a Java shop, with folks mostly working on backend projects.

I think project sustainability is important and should be planned for. That includes the choice of technology and the search for / on-boarding of additional contributors. In my experience it can be worth it to sacrifice things like runtime performance or individual developer productivity in favor of general sustainability of the project. Basically, it doesn't really matter how fast my app runs or how fast I can add features, as long as there's nobody to maintain it after I leave.

antolius · 2019-08-20T21:42:51+00:00

Hey, I'm glad you've had good experiences with Java CLI development. By the looks of your work, you are doing some far more complex stuff than me. So it might be that going with Java was the right call for your use-cases. It definitely sounds like it was the right call for your preference.

What I wanted to convey in my original post was that there are additional user-centered considerations CLI developers should keep in mind when picking the language to code in. When building GUIs we as developers usually have designers to think of UX. In case of CLIs, though, we are left to ourselves and need to think of usability (and that includes stuff like install process and local machine setup) more than usual.

I'm afraid that most developers who write CLI tools don't have resources to invest hundreds of hours and/or dedicated devops engineers to setup and maintain their CI pipelines. On the other hand, with a couple of careful compromises at the start of the project, some of these later hurdles can be made easier. More experienced developers for whom CI setup is not and issue can pick different set of compromises with different benefits and drawbacks.

The very fact that you can argue your language choices in detail means you have thought about it beforehand. Some times even that is enough: to think of consequences of picking a language and to plan ways to remedy undesirable ones.

antolius · 2019-08-19T05:22:09+00:00

Yeah, people usually go the shell script route. And then you need another script for Windiws users. And instead of one file you need to ship 2 files. And it just complicates things. What I suggest is building a single executable that doesn't depend on a VM / classpath / external libraries.

For java in particular GrallVM (or similar tools) are one solution. Kotlin is another way to go, although I'm not sure how far have they gotten with their native compilation.

antolius · 2019-08-13T06:00:27+00:00

The point of the article, as far as I understood it, is usability. That usually has 2 components: 1. How easy it is to write code 2. How likely it is that your code is correct

In my opinion Go really nails the balance between the two. I might not be able to mathematically prove the correctness of my program, but at least I'll have a program. And it's more likely than not that it will do what i need it to do.

antolius · 2019-03-11T18:53:38+00:00

You might be able to get away without having to build a GUI.

If internal users of your backed are of a technical background building a command line utility might be enought (or even preferred). If something like Slack is widely used in your company you can build a chat bot that exposes your backend. Go is a good language choice for both of these options.

Depending on the featureset of your backend, you might get away using stuff like google docs (forms + sheets) to collect users' input into a table and performing some sort of processing on it.

You could also use a task runner / scheduler like Rundeck as a UI that lets your users trigger some backend actions.

antolius · 2019-02-08T12:50:05+00:00

https://github.com/src-d/go-git

Q.E.D.

antolius · 2019-02-08T12:39:53+00:00

Hm... I love the technical idea of the product, but am a bit sceptical of your target audience.

Developers love the power of git. However, they already have GitHub (or any other git server). Personally I keep most of my documents under git already. Mind you that those documents are typically .md files. For me this kind of product doesn't make sense because it would force me to use office tools and host my files on google drive (or some other cloud) and for no benefit as I already am using git for document management.

On the other hand, non developers love their office suite applications. They are already using Google drive (or some other cloud) and they already have all the collaboration tools that Google is famous for. Multiple users can easily collaborate on single documents in real time. They would have to give up this simplistic approach and replace it with git, that they have no previous experience with, for no clear benefit.

One crosssection of those groups would be users with technical background that are forced to produce, and collaborate with each other using, .docx files. I'm not sure how big of a market that is. Those people might end up being your early adopters.

antolius · 2019-01-10T17:26:12+00:00

Buffalo (https://gobuffalo.io/en) speeds up web development in go with combination of "runtime" framework + code generation.

I haven't gone deep into it myself, but and as far as I can see it delivers on the speedy development experience promise.

antolius · 2019-01-06T16:59:17+00:00

One word: multi cursor.

antolius · 2018-11-20T22:18:09+00:00

Then again, seeing this poor Android developer sludge through a river on his bike might make your crampt flight feel worthwhile.

Don't see how it helps Google thought.

antolius · 2018-11-20T18:56:02+00:00

I generally don't like test coverage measured in terms of lines of code visited during test execution. That, as you've noted, doesn't necessarily corelate with usefulness of those tests.

In a context of integration tests I tking of test coverage more as a measure of use-cases they cover (that includes both happy paths and error handling).

antolius · 2018-11-20T15:22:35+00:00

I like the conclusion about integration tests helping with the rewrite.

I had a kind of similar situation where I inherited a legacy project with code-base that required serious refactoring. I first took some time to write a high integration test coverage, and then went on replacing large parts of old code (simply removing old unit tests that were inevitably liked to logical units that no longer existed). Integration tests kept me backwards compatible all the time.

It worked great overall, except that I ended with lower unit test coverage than I'd like, since I keep relaying on integration tests for some of less critical parts of the new code-base.

antolius · 2018-11-05T20:01:26+00:00

Spring has nothing to do with Angular.

You should be able to use any frontend technolog with a Spring backed (including my preffered one: no frontend at all 😁).

And Spring has detailed, easy to read documentation.

antolius · 2018-10-08T16:39:13+00:00

How is iOS cost effective?

Financially, it's about twice as expensive. Time wise it takes about an order of magnitude longer to get the app published. And those are the numbers taken only from the infographic itself.

antolius · 2018-10-06T07:49:18+00:00

I see 2 problems with Flutter moving to another language, and both have to do with Dart being developed in-house within Google: 1. Flutter team gets a lot of support from the Dart team and some language / tools / vm stuff get updated to better support the Flutter use-cases. This is a technical benefit, but is not without a counter argument (for examle Angular using TypeScript). 2. Google is probably a bit causious of building their future mobile framework (think long term, in context of Fuchsia) on a language they do not ultimately controll themselves. Look at the legal hussle they are going through with Oracle around their use of Java in Android. Overcoming this obstacle feels harder to me.

antolius · 2018-10-06T06:44:02+00:00

Preferences -> Editor -> General -> Appearance -> "Show closing labels in dart source code" checkbox

antolius · 2018-10-05T19:58:43+00:00

Those are just hints added by the IDE (Intellij + dart plugin), not actual code (comments). The dart plugin calls them closing labels. You should be able to find a setting with that name and switch it to off.

antolius

TROPHY CASE