snorremd

Tailwind CSS is a JavaScript library that produces css with utility classes that allows you to build a consistent look and feel in your web page. Unlike Bootstrap which exposes components like buttons, cards, input elements, and other components, Tailwind CSS gives you utility classes that handle padding, margins, colours, shadow, etc. Typing in Tailwind CSS utility classes feels very much like writing CSS. Each utility, e.g. mr (margin right), comes in various forms including sizing and with media queries. So mr-4, sm:mr-2, etc.

The value of the Tailwind CSS library lies in its templating and plugin system. You can very easily change what mr-2 means. You define it once in your template and it affects your entire app.

If you see repeated components in your app you can opt to create css components using Tailwind's JavaScript based configuration, though you can just as easily create the component as a React, Vue, or Angular component.

I used Tailwind CSS in a project and my favourite thing about it was how little I had to fight with Tailwind to get things to look the way I wanted. Tailwind does not dictate what kind of components you can build, it simply gives you good base utilities. With bootstrap you will need to build components from scratch as soon as you need something different from the ones that bootstrap has provided. And if you want a navigation bar, but want it to look slightly different you will have to try to override Bootstrap's css somehow.

Tailwind UI is simply a collection of finished Tailwind CSS components that demonstrate useful compositions of html and various tailwind utility classes to build common components. Instead of figuring out how to build a navigation menu yourself using Tailwind utility classes you can simply copy the example in Tailwind UI and customise it if you want.

Edit: Tailwind CSS only produces CSS. It does not provide any JavaScript for you components. That you will need to build yourself. There is no Tailwind.js to run in your browser to handle multi-select dropdown inputs, etc.

I did a project where we used ClojureScript both on the server and the client. The server ran on Node.js and so most libraries could be used on both the server and client. We used reagent to render our app which made it possible to use reacts render DOM to string functionality.

Essentially the app was developed as an isometric app, and we had some additional stuff in the server part of the application.

While running ClojureScript serverside might not be everyone's cup of tea, it worked well for us.

Clojure's extensive support for lazy evaluation and sequences actually makes it decent for command line tools that process streams of data. At least in terms of program architecture and elegance. The biggest mismatch used to be startup time, but with GraalVM you can get very good startup times.

I made a couple of simple command line programs at my previous workplace and the functional style of Clojure combined with lazy sequences made processing an unknown amount of resources on our server a breeze.

I would think that the language of choice for a command line program would have more to do with the task you need the program for and not the command line format itself.

Obviously for performance critical stuff such as implementing something like ffmpeg you would want to use rust to squeeze out every last bit of performance.

FIDO2/U2F support is still an experimental feature in Firefox, but can be activated with the "security.webauth.u2f" setting in about:config.

But then you switch out your issue tracker service from something like Jira to something else, and suddenly that ID or URL means squat. A git repository can easily be pushed to any git based service be it GitHub, GitLab, Gitea, or something else, and the commit log and commit hashes stays the same.

Porting Jira issues to a different system would probably not preserve those IDs that you entered into your commit message. By all means, refer to your issue tracker in commit messages, but be aware that those references may not be valid in a few years.

Internet Object, from my limited read-through, seems to be order sensitive in a way that JSON is not. If you define a schema at the top with the available properties in some order then the values must follow that same order.

And what happens with sparse data? In JSON you simply omit the properties (key value pairs) from the JSON object all together when there is no data for the given property. For Internet Object you presumably need to insert "null" values in the column you have no data for?

I can see how omitting the "header" names from each "object" in a vector/array of objects can save space, but there are no mentions of trade-offs. And if you gzip a JSON body then the compression algorithm will get rid of those repeated bytes in any case, at the expense of some additional CPU resources being used. Running the example data through gzip proves this:

Original sizes:

- io: 51K

- json: 88K

gzip sizes:

- io: 20K

- json: 21K

The more interesting tidbit was the embedded schema for validation of data I think. The splitting "headers" and data seems less important. I also think maybe showing some speed comparisons of serializing and deserializing internet object and json data would be nice. Though this would necessarily depend on using the same programming language and writing an optimal internet object serializer to get a fair comparison.

This comment might come off as overly negative or disparaging. Kudos to the author for coming up with a new data format to solve an observed problem.

I really enjoy the Failjure library [1] to make threads that short-circuits on failures. This is pretty close to what monadic error handling looks like in strongly typed functional languages.

[1] https://github.com/adambard/failjure

I think what the comment you are replying to are getting at is the fact that installing pip packages from the Internet and importing them in your python app is not that different from piping code from the Internet into your python executable. In both cases python code from the Internet will be executed with your user privileges from within Python. Unless you audit every python package you consume, you might as well accept a curl https://example.com | python installer too.

It is not that long ago that PyPI hosted malicious (typo-squatting) packages: https://news.ycombinator.com/item?id=15256121

> While Storm's Clojure implementation served it well for many years, it was often cited as a barrier for entry to new contributors. Storm's codebase is now more accessible to developers who don't want to learn Clojure in order to contribute.

While I appreciate that programmers have limited free time and may not want to learn a new language to contribute to open source, I feel like learning Clojure could be of value to the programmer in itself.

The supposition that Clojure acts as a big barrier against contribution from developers might be true, but I really feel like developers who only write code in the ALGOL family of languages are missing out. Learning a lisp language is not an impossible task and can improve your skills as a developer.

If you know a bit about GitLab and Docker, GitLab CI is pretty easy to grok. I really enjoy that you can run your CI jobs inside any old Docker container (with a shell). GitLab CI is built up from very simple concepts and functionalities, but still enables some powerful use-cases.

The artifacts feature is great and some artifacts, like unit test report files, can be interpreted by GitLab and used in various parts of the GitLab web UI. A lot of this just works and most of the CI features are available in the GitLab community edition which is open source.

I have not used Jenkins actively since before the Jenkins pipeline file format was common. So for me Jenkins always appeared to be this game of checking the right checkboxes and clicking the right buttons in the Jenkins UI. The new pipeline feature is probably much nicer. However, now that I use GitLab I don't really see any reason to switch back to Jenkins.

The good old 2015 MacBook Pro keyboards were super nice. Why change a winning formula? Was it the quest for ever thinner laptop bodies?

I'm hoping Matrix (matrix.org) will have more success.

re-frame (https://github.com/Day8/re-frame) essentially implements the ideas and patterns presented in the article/post. Of course you would need to learn ClojureScript to use it, but that might be worth it.

I really like the "selector" pattern. Your app state should not have to reflect your UI component tree. Rather you use selectors to subscribe to some part(s) of your application state and derive any necessary values in the subscription/selector function.

Representing your app state as a single source of truth and expressing all changes to state as effect handling functions means you can now easily test your front-end app without involving a dom at all! It is state transitions that are interesting.

Of course there are other options like Redux and Vuex for React and Vue respectively as well as the elm language if you want to go all in on static types and compile time error checking.

I suspect some places still only use passwords for server logins because they can simply use active directory for user management and then have servers use ad/ldap for credential checking.

I think businesses with critical infrastructure should use hardware keys (e.g. yubikeys) to provide at least one of the factors needed to log in to a server. Using a yubikey as an authentication key for ssh is not that difficult and I do it for my own hobby stuff.

For web based stuff one can now use webauthn to provide key based authentication (in addition to whatever other factors one would like). This requires the enterprise to run up to date browser however.

The solution to keyloggers is not partial passwords. The solution is requiring two factors! In Norway there is a shared authentication infrastructure used by banks and other services called BankID: https://www.bankid.no/en/private/ They facilitate second factor auth either with an OTP device or via your cell phone's sim card. It just works.

All Norwegian banks use a password + second factor. And these days I think most of them have liberal password rules, in that you are allowed quite long passwords. Schemes like the one described in the post seems like a poor attempt at improving security.

For desktop ProtonMail has a bridge to allow you to use standard imap and smtp: https://protonmail.com/bridge/

I guess for mobile phones you need to use their app.

Now that we have the GDPR law I would almost think a clear exit experience would be necessary to truly comply with the law as well. An EU user should be able to request her user to be deleted together with her data. At this point you might as well make it a nice button on your service's profile administration page.

I've not used C# and .Net Core in any real capacity so thank you for the corrective comment. I think some newer languages are getting tooling right, like rust and to some extent go (though dependency handling has been a sore thumb).

Maybe C# is really only fantastic on Windows with Visual Studio?

My anecdotal feeling is that most popular JavaScript libraries expose promise-returning functions these days. Browsers and Node has supported Promises for about four years, and async/await has been around for about two years. I have not personally had much problem using async/await with third party libraries. And wrapping those that use good old callbacks was pretty easy all things considered.

Yeah. My impression is that C# rules the world of enterprise and fintech software, at least here in Norway. It might be different elsewhere.

It seems like a good language with very good tooling if object oriented programming (in the Java and C# sense) is your posion of choice. Now with .Net Core and other good iniatives from Microsoft it might be a more relevant language than ever.

If GitLab can pull off the npm registry well this might be the beginning of a universal package management server built into Gitlab. A bit like the self hosted Nexus registry or Artifactory.

Not sure if it wouldn't be just as well to run Nexus OSS instead though? https://www.sonatype.com/nexus-repository-oss

You might not get as tight of integration as Gitlab will provide, but the Nexus OSS repository provides some nice features in terms of cleaning up old artifacts, some disk usage policies, etc.

Edit: Saw that you are not the author of the merge request. Then thank you for highlighting it.

Oh jolly good! This exact feature was something I've thought about as useful for microservice stacks where you need interconnected background services for integration testing. Very nice of you to contribute this feature, thanks! Hopefully this will be merged at some point.

Yeah, my mistake. From what I gather after reading more about it one only has to take care to dynamically link the qt parts when compiling a binary.

They use a dual licensing model, one copy-left and one commercial. To be specific they use LGPL, not GPL. http://doc.qt.io/qt-5/opensourcelicense.html

If you don't want to abide by the LGPL requirements you will have to fork out 459 USD a month. For an established development company this is not a big deal, but for a side project?

Considering all the Electron criticism that permeates every single "show hn" thread about apps written with Electron I have to symphatize with the author's remark.

There are legitimate technical grievances with Electron, but how many time must those be expressed? If we data mined every Hacker News comment for negative comments about Electron would it be considered big data? I just don't think the persistent Electron criticism for each and every Electron app is very productive.

As other commenters have expressed. If someone could provide an example of an alternative to Electron that provided the same affordances (multi-platform, open source, permissive license, proper web view support), then by all means.

Not everyone is Spotify and can invest the technical know how to make things with Chromium Embedded Framework. To this day the Linux client for Spotify is not an officially supported client. It is something the Spotify developers maintain of their own volition.

And QT, a popular window toolkit, is quite expensive unless you release your software under GPL (at which point you can use QT for free under the GPL license).

Also, a single maintainer does not have time to work on three or more window toolkits for their app (Windows Forms, Cocoa, and GTK).

Maybe Github Actions qualify? https://github.com/features/actions I must say it looks almost like Gitlab's pipeline system, but somewhat more flexible. If Github's free plan allows you to use pipelines I might just have to test it to compare.

The datalog like query language combined with immutability is quite nice. I'm no expert in Datomic yet, but it is pretty nice that the queries are simple Clojure data structures. I can use regular old Clojure code to build queries dynamically (if needed).

I quite like tools.deps, but it is maybe a bit problematic that it is bundled with the Clojure install. Before tools.deps there were no officially sanctioned dependency and project management tool. This is probably why we got both leiningen and eventually boot. Now the bar for choosing something different than tools.deps is probably going to be quite high.

Sadly tools.deps lack the support for reading credentials from a gpg/pgp-encrypted file: https://dev.clojure.org/jira/browse/TDEPS-9 This is a shame as I rely on this to keep repository credentials safe. I'm not a fan of the maven master password system.

I think so as well. When you have macros and can add syntax and features to a language at will, then the language and core library does not need to be very big. This probably helps immensely when trying to avoid breaking changes.

New macros can very well be prototyped and battle-hardened in external libraries before being added to core.

Agreed. The tagline talks about any programming language, and then the classes section goes on to talk aout classes, abstract classes, class hierarchies, etc. To me it seems like "any language" in that chapter at least would refer to what people traditionally call object oriented languages.

Lisps, some low level c-style languages (go and rust among the newer ones), and some ML languages with algebraic data types don't really have the same object orientation abstractions as Java, C#, and Python. Further more the class system in Javascript ES6 are a bit special.

It would be better to talk about domain modelling, suggest interesting domains to model, without actually specifying any particular way to do it.

Edit: I must add that the author have done a great job of collecting these suggestions for tasks though!