915 karma · joined September 2, 2013
https://hnbadges.netlify.app/?user=AlphaGeekZulu
I definitely believe that computer programming can be art!!
But it might not make it into an all-accepted major art form. The audience for this art as well as the emotional impact are too small.
I am a computer programmer and I am emotionally reacting to some code that I get to see, but this is a very intellectual and weak emotion compared to the ones mentioned above.
I really spent endless hours thinking about, if computer programming could ever be executed on a stage and attract many people. Found nothing yet. I believe, maybe, computer programming can only be used indirectly, by producing music and other art that triggers emotions on many people, but not by itself.
This theory of course is based on my personal assumption, that arts are defined by their ability of triggering strong emotions on the art consumer.
The idea of Remind is to have every scheduled event of your life in a plain text file (or a collection of plain text files). Remind is like a markup-language for time and it supports extremely complicated rules for repeating events (like: garbage is collected on mondays every two weeks, but not if the monday is a holiday in which case the garbage is collected on the following tuesday - in any case remind me the evening before the actual day to put out the trash can). And if your scheduling demands exceed Reminds language features, you can use its internal Turing-complete API for setting up your own rules.
In my opinion there is nothing better than a plain text file for keeping scheduled events and I am obsessive with my Remind files. As a software developer, I have my text editors (VSC + Emacs) open all day and there is no faster way to write down an event than typing a line in my Remind file. I probably used more than 50 calendar tools in my life - standalone and cloud based. In many of them it was simply ridiculous how complicated it was to enter an event with reminder and repition rules: mouseclick after mouseclick, popup after popup, clicking tiny arrow-icons eleven times to set the month to November ;-)
I collect EVERY event of my life, sometimes many years in advance (for example, my Remind files contain the expiry dates of all important documents, end dates of subscriptions with their respective cancellation periods, anniversaries and such).
Next, Remind is a command line application, that allows to display the contents of the Remind files as calendars in the Terminal or export them for a given time range. The export options include different versions of plain text and HTML and whatever else the Remind community came up with. I made my own script, that utilizes the Remind CLI to produce an interactive HTML-calender with 5 different themes exactly to my specifications.
With Remind I own a consistent diary of every scheduled event of my life in the last 20 years. I never forget a birthday, miss a deadline or accidentally renew a subscription. My raw data is readable in a text file. I have full control over backups and encryption and my data will be usable even if Remind ceases to exist one day.
This made my day ;-)
This article is almost free of information and the conclusion is a slightly extended version of the headline:
"[...] So, do aliens exist? Many scientists believe that humans need to work even harder to determine whether there is extraterrestrial life out there, let alone whether or not aliens have visited Earth. [...]"
The opening question remains unanswered.
https://www.livescience.com/chinese-long-march-rocket-uncont...
The reentry is uncontrolled by design:
"This, sadly, wouldn't be the first time. In May 2020, a Long March 5B rocket slammed through the atmosphere, partially burning up on its descent, Live Science previously reported. The core fell largely into the Atlantic Ocean, but some debris landed in West Africa. According to the South China Morning Post, some chunks of debris crashed into inhabited villages in Côte d'Ivoire, though thankfully no casualties were reported."
I recommend the book: "Refuse to Choose!" by Barbara Sher.
Short intro: https://www.getmotivation.com/motivationblog/2017/04/barbara...
In short: get over the feeling of guilt first, then organize your multitudes of interests.
But lets take the second sentence for itself. Actually it is two statements:
1. Light themes are much better on the eyes.
2. Light themes look much more pleasing.
I will skip 2., this is about personal taste, nothing to discuss about.
So, are light themes much better on the eyes? I was educated in the 1980s as a typesetter and it was an unmistrusted truth back then, that a maximum contrast with black font on white background is the most readable representation of text. This was backed by scientific research which measured the reading speed. It was also deduced, with not so much scientific research, that the maximum reading speed also means maximum relaxation of the eyes (if contrast is poor, eye has to adopt, focus, use muscles, is more strained). White background at that time also meant: paper (nonluminous color).
I have not followed research in the last 20 years and wether it has be redone with different results, especially for luminous colors.
But I have a 43" monitor now, and what I can tell for sure: the amount of light that hits my eyes if everything is on light theme is simply blinding! I am all dark mode in the long hours of work in front of the monitor, but I will switch to a light theme if I have to make a presentation or share the screen. Because dark mode requires a super sharp resolution and perfect font hinting. Readability of dark mode will suffer significantly, if scaled down or reduced in quality (which typically happens on remote connections, screen sharing or presentations).
The reason for the rather complex implementation with a backend is, that we actually did not have Social Media Image Cropping in mind when we started development more than two years ago. The problem we set out to solve is considerably larger: how to automatically crop an image into any aspect ratio with a guaranteed acceptable outcome (key elements intact and the image composition as good as possible). This challenge is a pestering problem whereever publication workflows are automated: "Content/XML first", Template Driven Publishing, eBooks, websites and so much more (how about destination mood images for the airplane eTicket on your mobile device?).
Standard procedure as of today is to decide for a set of primary aspect ratios (for example 1:1 for the thumbnail of the article list view, 4:3 for the article preview on the landing page and 16:10 for the actual article), manually crop the original image into each of those primary ar's, store them somewhere and build the publication workflows to automatically choose the respective version and scale it to the final dimensions. There are a couple of tools within modern DAM systems to assist with this approach (like dedicated cropping frames for each primary aspect ratio in an image editor), nevertheless this approach is cumbersome and inflexible. What, if the art director decides to change the website layout and go for a new aspect ratio for the article images? It would be necessary to recrop the entire image archive.
So we tried AI and image analysis. Some image types work very well - face recognition, or typical stock photography with a blurry background for example. But while the results of AI image recognition are sometimes astonishingly good, it nevertheless fails on multiple levels. A significant percentage of AI croppings fail completely for whatever reasons, or the result catches the focal area but loses composition aspects (e.g. asymmetry) unnecessarily early, or the AI is simply missing the context (if there are two people on the photo and I can only show one in portrait, who shall it be?). If there is only one percent failure in the AI approach, it cannot be used in fully automated workflows without a follow-up result verification process.
In the end we concluded that only a human can reliably decide about the recomposition of a motive upon aspect ratio change. So we invented a method to apply an universal cropping hint (once!), store it in the image metadata and then have an algorithm, that can calculate the resulting cropping rect for any aspect ratio from that cropping hint. The cropping hint consists of a number of elements (some user-interactionable, some hidden) and it took us more than a year to finetune the cropping algorithm. This technology is our core product (that we want to make money with) and it is called qCrop (certainly worth its own "Show HN" as soon as we have finalized the API). So, qCrop consists of the cropping hint format, the cropping algorithm and the services to use the technology in automated workflows: a client to visually apply the cropping hints and embedd them into the picture files (this part should actually be implemented in DAM systems) and the cropping service, which can deliver cropped versions of an image on demand with simple parameterized http GET requests.
Now this is complex stuff and how are we going to explain it to a potential customer?
Here comes Cropping.Rocks: a minimum viable product, a single page app with only a few lines of HTML and JS incorporating the qCrop backend. A technology showcase for our potential customers and a free time saver for social media professionals ;-)
I am definitely going to add some sort of visualization of the final result to the page...
This app is a MVP for our qCrop technology: a way to easily and quickly provide an image with a universal cropping hint, which is valid for any aspect ratio. The cropping hint is embedded in the image's metadata and then respected by an automated cropping backend.
qCrop is written in Rust and WebAssembly as a unified microservice and deployed as docker containers.
176.552°O
(north-east Russia)
OPS 6182 (10820, 1978-042A): https://www.n2yo.com/satellite/?s=10820
SL-8 R/B (12443, 1981-041B): https://www.n2yo.com/satellite/?s=12443
They are on head-on course. With a probability of about 80 percent they will miss each other. With a probability of more than 20 percent they will impact at a speed of more than 50000 km/h in an altitude of 780 km.
The two objects are not important (an old Russian rocket piece and an old US weather satellite).
But upon impact, the objects will create a large cloud of debris, that might collide with more objects, in the worst case in a chain reaction.
The danger is not falling debris, but that they will produce more damage in their orbit, maybe hitting more essential space equipment in the future.
No need to hide in a bunker.
On the other hand: if there is still any living person out there voluntarily displaying HTML mail as such, they probably want to suffer. So, ok.
I won't see any of it anyways. HTML-designed mails go straight to my bin...
- MacOS/Firefox - Ubuntu/Firefox
I can enter space in the search widget on
- Ubuntu/Chrome - Ubuntu/Brave - Ubuntu/Opera - Ubuntu/Vivaldi
299792 segmentation fault (core dumped)
There is a comprehensive description and history of the Tyler Slide Rule in German language at:
https://www.rechenwerkzeug.de/tylerbausatz.htm
A very good review in English language is available here:
https://osgalleries.org/journal/pdf_files/9.1/V9.1P23.pdfOnce adapted, it is impossible to change afterwards.
Drones are even more complicated: left hand/right hand preferences (regarding power and lift) can never be re-learned, so most remote controls come with multiple configurations.
However, the underlying core problem of the vulnerability is absolutely independent of any specific component, vendor, product or policy. The core problem are developers not thinking their stuff out. Reading from a file is an absolutely non trivial task, million things can go wrong and the responsible developer has to foresee and handle them all in a generic sane way. Maybe do not read until EOF, if you never expect more than a few bytes? Read the file async with a timeout? Taint the input? Do not put the system in a dependent, unsecure state before success of the operation. Expect stuff to fail and code accordingly! Think like a hacker and try to hack your own code. And do this for any single line of your code.
I learned to introspect my code in this way as a byproduct of learning Rust. It began with Rust's strict type system, which forced me to carefully consider each and every value and variable and how I toss them around and how and where and how long I am going to access them in my code. It continued with the error handling policies of Rust in a similar way. The learning curve of Rust was steep for me and coding the first months was tedious. But once I got the hang of it, I started to love it. Fighting the compiler, I have to go through every aspect of my code in a super careful way over and over again and once the compiler gives the Go, I feel love and appreciation for my code - as if I crafted something special, that was approved by the master. Code no longer was for me something thrown into the editor as fast as possible with just the effort to make it run somehow reliably. I felt now, as if my code was a piece of art, well thought out and beautifully crafted, made to serve for many years, like a musical instrument. In other words, Rust was changing the appreciation of my own work and gently shoved me to a more careful approach of coding.
At some point in development I go through my code to do some manual formatting, you know, aesthetic stuff like indenting to make the code look more beautiful (in a human way, not a linter's way). Like a last polish. And on this run, I look at my code as a hacker. How would I crack it? How would it handle that and that exception? I try to think really evil. I think many programmers shy away of this step, because it can mean a lot, a lot of new work. And this is where Zero Days as the one described in the thread originate.