DEV Community: tharos70

Logseq - Yet another knowledge base tracking tool?

tharos70 — Thu, 15 Dec 2022 17:11:56 +0000

Context

If you are a curious developer like me, you may be in constant search for the best tool for tracking what is generally called Knowledge basew and logging daily activities. I've tried several tools but I often fall in love with some of them and then I find others better in resolving specific needs. Let's see those I tried from an individual usage perspective.

Options

Notion:
- PROS: Fast learning curve, great flexibility, full text search, templates. Data stored in the cloud are accessible almost anytime and anywhere. Free (so far)
- CONS: It becomes a mess if you don't approach it with extreme attention at organizing things. Too many templates and functionalities to try. Is this a pro or a con? For my state of mind it is a dramatic con... It may not be the same for everyone.
Google Keep:
- PROS: Fast learning curve, full text search, tags. Free (so far)
- CONS: After years of usage it is a mess.
Clickup
- PROS: Free (so far), lightly project management oriented, templates, fast learning curve
- CONS: Some functionalities are available only if you pay. UX is not so easy to understand.
Airtable
- PROS: Free (so far for individuals), fast learning curve, it is essentially a classic database.
- CONS: If you don't often deal with database you may find yourself unconfortable. Filters and grouping are not for beginners.

Logseq

Is this better than the previous tools?
Short answer? No.
Longer answer: no but....
Logseq has a bit different approach which made me curious about it.

It works locally, so it implements a privacy by design approach. It is just something that works on files stored under a specific local folder and it has predefined object to work with, such as:

journal: where you can store your daily activities
pages: where you can create your organised Knowledge Base content
logseq: where it stores its internal configurations, styles etc.

And then there are some interesting features which I think are one of a kind:

The graph view: this is something which grows as long as you create links across your pages. It lets you analyze your knowledge base by highlighting relations between different topics
The presentation view automatically converts pages into a live presentation document.
The flashcard item lets you create some sort of information dialog directly inside the page.

Conclusions

This is what I discovered so far in about a couple of weeks working on Logseq. This is not a game changing, though it has some features which I had never seen in other similar tools.
It's definetely worth checking out.

Bonus:

Introduction video:

Logseq Documentation

A simple guide to Java http calls

tharos70 — Fri, 02 Dec 2022 14:57:19 +0000

Introduction

When it comes to consume an api with Java there are several options. One of my fovourite is Square's OkHttp.
It is a well known, full feature and highly customizable library which is moreover very easy to deal with. I noticed, in my daily job, that most of the times I have to deal with problems which force me to change my approach in calling APIs/Urls. That's why I decided to write a few recipe classes in order to organize my job when it comes to this topic.

The OkHttpClient API documentation states very clear that:

OkHttp performs best when you create a single OkHttpClient instance and reuse it for all of your HTTP calls. This is because each client holds its own connection pool and thread pools. Reusing connections and threads reduces latency and saves memory. Conversely, creating a client for each request wastes resources on idle pools.

In order to do this I set up an OkHttpClientInstanceHolder class so that in every call I need I can relate to the correct instance.

Why do we need different instances? Beacause we may want to have different flavoured http clients (ex. proxy enabled, with or without ssl channel checks, with or without a timeout handling, etc.)

Here are some of the HTTP request examples available in the repo:

GET

Simple GET Call: Performs a simple http GET call to the specified url with the specified query parameter.
Simple Get Call Timeout Aware: Performs a simple http GET call to the specified url with the specified query parameter with a specified timeout expressed in millisecond. When the timeout occurs, the call will be canceled.
Simple Unsafe GET Call: Performs a simple unsafe http GET call to the specified url with the specified query parameter with a specified timeout expressed in millisecond. When the timeout occurs, the call will be canceled. It is unsafe beacause in case of an https url call, the certificates chain will not be checked. It is not a recommended usage, but sometimes it may be useful for troubleshooting purpose.
Simple Async GET Call: Performs a simple asyncronous http GET call to the specified url.

POST

Simple POST Call: Performs a simple http POST call to the specified url with the specified json payload.

PUT

Simple PUT Call: Performs a simple http PUT call to the specified url with the specified json payload.

DELETE

Simple DELETE Call: Performs a simple http DELETE call to the specified url.

A complete list of the available sample calls can be found in the readme of the repo.

Please feel free to fork and submit you CR.

Here's the repo link: https://github.com/tharos70/http-client-samples.

I hope you like it!

GIS Viewers - reducing the impact of technologies upgrade

tharos70 — Fri, 28 Feb 2020 08:29:52 +0000

Long story short...

After talking at 2020 foss4g Italy event, I was asked to publish my slides, but, since they're in italian language I decided to write a little summary of what I talked about.

FOSS GIS viewers

GIS web viewer share often a similar architecture.

As you can see from the image above a GIS (Web) Client is a bunch of html and js files which can handle access to some Web services standardized by the Open Geospatial Consortium. There are many FOSS projects out there providing common functionalities of a web viewer. Lower level ones like Openlayers or Leaflet, and some more engineered solutions like Mapstore2, Geoadmin or Geomapfish. What happens anytime a technology upgrade occurs on the client side?

Development lifecycle

The image above, describes the classic development lifecycle. What happens when we happen to be in the green phase (Evolution) and the evolution includes an important technology upgrade (for example like when you decide to rewrite your software in a completely different programming language)? Typically you may be able to reuse Requirement Analysis, maybe some design, but all the next steps will need a complete rewrite. What can we do when such an event occurs in the development of a GIS Web Viewer?

The approach

Well in my company we have setup a software solution in order to keep as much developed software as possible. The concept is quite simple. We have a three step process:

At configuration time, in a QGis project we handle the organization of the TOC and all the OGC services we want to use in our specific context. Then via a QGis plugin, we wil enrich the configuration model by adding informations about tools we may want to enable in that specific application (like features searching, graphics specifications, feature fusion, cutting, etc.). Then all this configuration data is stored in a DBMS via a REST API. The specific configuration is identified by a UUID that will remain the same throughout the technology upgrades.

As you can see from the image above, at configuration time we have set up our viewer context and stored it in the DBMS. When a viewer needs to access the desired configuration, it has to present itself by the corresponding UUID to its specific API. So what happens behind the scenes is a Model To Model conversion: from the ER model of the DBMS to the domain specific one of the requesting viewer. Furthermore, there's a Tools api which needs some more explanation. Tools are components with a specific configuration and an optional specific API. These objects are transversal to the frontend technology, so as the supported frameworks increase in number the available tools needs the only presentation logic to be reimplemented, while the backend API remains untouched.

Pros and Cons

So, what do we gain by approaching GIS viewers development in such a way? First of all the choice of using a Model driven development makes the whole ecosystem of configurations highly reusable (for example you may want to publish different viewers displaying the same configuration). Another interesting feature is that the modular architecture enables us to increase tools and features that can be added also to older configurations as long as they're made available to the ecosystem. And now some cons too. What we are doing here is some heavy integrating duties, that said it's obvious that choosing to support someone else work (a.k.a. FOSS framework and libraries) we have to compromise to some UX/UI choices that may not be suitable to every needs. But hey, there's plenty of them to choose from so that can be an opportunity to integrate one more community! And then the worst con IMHO: this approach leads to a highly configurable system. Which means that if you don't plan a heavy integration test plan you may occur in some serious problems (like setting up a viewer for production pointing to an internal API. Real sad story…)

What's next

We are planning to publish all this ecosystem under FOSS licenses in the next months in an incremental way. When all the documentation and the code will be available I'll publish a short recap. For now you can check our organization on github for some interesting FOSS projects.