June 21 is approaching, and I wanted to visit a place where the Tropic of Cancer passes through just for the fun of it. But I couldn't find any interactive maps showing the Tropic of Cancer line. So I built a simple website that shows the Tropical lines, and we can pick a nearby location to get directions.
I found that this saves a lot of battery. My old Motorola G5G is now sitting idle, and I had to charge it every 4-5 days. I found that if the phone is restarted and NOT unlocked, it will stay charged for more than 10 days. My best guess is that a screen unlock is required to start many of the OS-level services, which takes up all the battery.
If this is true, then the new update will save a lot of battery for those phones that are sitting idle.
I have 3 phones, for various reasons. Not SIMs, but 3 devices. The usage is radically different between them. 2 of them are used daily but even there one routinely runs out of battery and other does not dip below 80%. The third one gets used when it gets used :)
This took me a nostalgic dive back to 2000's when a website called planet-source-code.com was popular among the developer community. It had hundreds of mini operating systems written by members. Most of them were written in C/C++ and Assembly for the bootloader, compiled using Mingw32, and booting from a regular Floppy disk.
I used Java for a while and then switched to Kotlin as my daily tool, and one interesting thing that I found was that Kotlin prevents inheritance by default, and the developer has to explicitly mark a class as "open" to allow inheritance. Eventually I stopped using inheritance and now prefer to use composition over inheritance wherever possible.
So the kicker in imperative OO for composition is that the class you are composing has some state / instance vars.
How do you include methods that can view/update those instance vars?
Sure it's easy to compose with static/pure functions.
Do you enclose the instance vars in holder classes and pass those holders to the composition implementation class in it's method signature?
In the end, inheritance or composition is about constructing a class /struct/whatever with a given set of expected signatures with some ideally documented guidance on any intricacies.
I am eagerly waiting for software test frameworks to adapt LLM where I can simply write test cases as easy as - "Open the website, login using these credentials, click the logout button, go back to the previous page, and check if the user is not logged in" - and let the LLM do the job.
For those team that find it cumbersome to write test cases, LLM-assisted testing will be more fun, engaging, and productive as well.
Why did they name those props `justify-content` and `align-items` instead of `main-axis-arrangement` and `cross-axis-alignment` which makes more sense?
There is probably some explanation, but in general, I find many CSS properties confusing and unintuitive: `color`, `text-align`, `position: absolute` vs `position: fixed` (absolute is still technically relative!), etc.
Everything is laid out on the page in a flow, according to DOM order. Think how a typewriter produces text on a page: top-down, left-to-right. This is the flow.
Absolute takes the element out of the flow while relative maintains it in the flow.
What isn't clear (even to many experts) is that certain properties change the layout model entirely and that text has its own "pushing" box that contributes to sizing.
Either Google has shifted _so much_ focus to getting an LLM to tell you about very real Encanto 2 spoilers that its search capabilities have atrophied, or my surprise at there not already being a Tailwind plugin for this is justified:
Is it, though? How much easier to refactor it in the future can it be, other than being able to search-replace Tailwind classes when the need arises to?
Well, what is it then that is so complex about Tailwind? I’ve been hearing that for so long, but nobody was ever able to explain succinctly what Tailwind made so awfully complicated.
I strongly disagree; any large project using CSS tended to have arcane names for everything and turned into a Tailwind of its own, but worse.
I also like Tailwind because it’s so self-documenting. Even if Tailwind’s development were to stop, tomorrow, and all of the style sheets were lost globally, I would know what everything is meant to be.
Bull. I have no clue at this glance what .input specifies, or what I can override without a conflict. Heck, .input might not even exist, resulting in only stock browser styles. The bottom one, I can fully picture while it isn’t much longer, the above is opaque and gives me no information at all about the look.
Secondly though, and why this opinion is frankly stupid, is that I can just put this in my CSS code before it’s built through Vite:
It says ”input” right there in the classname. @apply might be the only sane way to use Tailwind, but it seems like a post-hoc mixin construct, and definitely has the same level of indirection of styles that you claim is an issue with classnames.
Strange you would be worried about accidental overrides with class selectors but then go ahead to target styles with tag selectors. Is that not objectively worse?
Btw, targeting input[type=”text”] means now you cannot apply those styles to a regular <span> or <div> using a class, which is sometimes useful, especially in very large projects.
I am still not at all convinced Tailwind is even slightly useful. It feels like shoehorning HTML4 <color>, <font> etc. into HTML5 classes.
All in all, your arguments come off as ad hoc rationalizations for a personal preference, not as substantial examples of Tailwind’s superiority over more traditional CSS approaches.
Solve a simple algorithm/problem every week in your fav programming language and commit. This is for people who stopped day-to-day coding professionally, but still write code for personal pleasure.
reply