malikolivier

Once you enumerate what your development pipeline actually depends on, you will see it rely on a lot of stuff. A typical CI run pulls from npm, PyPI, Docker Hub, a distro mirror and a handful of third-party, none under your control, none with an SLA to you. Third-party outages, yanked versions, compromised packages are the things that can waste your time. Some packages may also drop support for whatever distro you're still using, and the mirrors may disappear (e.g. older Python versions, ROS, etc.).

Shameless plug: To fix all those development pipeline issues, I am working on StableBuild, a tool to easily freeze and pin Docker images, operating system packages, Python packages, and arbitrary build dependencies; in 5 lines of code: https://stablebuild.com .

This is to solve such issues that I am using and running StableBuild.

It is a managed service that keeps a cached copy of your dependencies at a specific time. You can pin your dependencies within a Dockerfile and have reproducible docker images.

It should be noted that only Modern Standard Arabic (the modern common Arabic language based on the language used in the Qur'an) still has dual. Most (if not all?) spoken dialects, which evolved from this form of Arabic have already lost dual.

It's interesting that we notice a similar pattern of losing the dual in many languages. And it would be very interesting to find the opposite pattern: a language where the dual newly develops out of nowhere. However, I do not know of such language.

This is exactly to avoid this kind of issue that I decided to work on StableBuild. StableBuild pins and hosts a copy of your dependencies at a specific freeze date, so that your supply chain is never contaminated. This way, a compromised version published after your freeze date (even with the same version number!) would never reach your build.

Such issues is what brought us to keep native honeybee species where I live, and not the domestic Western bees. The productivity may not be as high as the domestic bee, but we still get honey and it's very good! You would also notice the difference in taste. Apis mellifera honey is usually sweeter than the Asian honeybee, and not as prone to fermentation. A slightly fermented honey is also super good!

I did not know the existence of this manual. It was a very interesting read! Especially after page 28 (General Interference with Organizations and Production).

I encountered a similar situation in my career. The work looked good, the team looked good, money was good.

Then when the work contract came up, there were some unusual clauses about my salary that I was not comfortable with. They first said that it was OK to ignore the clause as they would pay my salary as explained orally. I insisted that they write the work contract as they plan to pay me. After about 1 week of back and forth, they admitted that the clause was indeed unusual, was there for historical reasons and that they plan to change it in the future. However, they said no clause in the contract could be changed as of now, as it was the same contract for every employee, and no past had employee ever complained about it.

Unfortunately, I ended up declining the offer, as I considered the risk was not worth it.

If I remember correctly, the properties mentioned in this document are well-known and commonly found in mushroom field guides or scientific literature written in the Chinese language.

I've been to Yunnan and have eaten that mushroom too (properly cooked!). We can find closely related species to this one in the wild in Japan too, but documentation for those Lanmaoa species found outside China is currently lacking, I believe.

EDIT: Found the field guide I was thinking about on my shelf. It's "中国真菌志 牛肝菌科(III)" [1], which is only about boletes!

[1] https://baike.baidu.com/item/%E4%B8%AD%E5%9B%BD%E7%9C%9F%E8%...

I've never smelled cannabis before in my life and don't know what it's supposed to smell like. I live in an area of the world where it's illegal and I guess not many people are smoking it. I may also have had a quite sheltered education.

This year, I went to British Columbia, and there was this weird scent everywhere that I could not describe. My wife said it was cannabis. I'm still not used to it so I don't know if I'll be able to recognize it next time I travel to North America.

I know companies that are posting vacancies that currently don't exist in order to keep good candidates on the hook. They tell the candidate that we should keep in touch for when the company is ready to hire them.

I am not sure if it's bad or not. It's true that it kinda wastes the candidate's time. In some cases though, the candidate is so good that the company will create a position just for them.

Is there anything I can do at a small scale on my own to sequestrate carbon dioxide? For example, I could install solar panels and use them to power a machine that sequestrate carbon dioxide. Does such technology exist?

After trying to reduce our emissions as much as possible, what kind of "best" choice to we have next?

Google is in Japanese on my side.

I get the following:

  2022. 開始:
  3月12日 土曜日
  終了:
  3月13日 日曜日

Which translates as:

  2022. Start:
  Saturday, March 12
  End:
  Sunday, March 13

Interestingly, this is a different result from what is reported by other people here.

For "last day of february 2022", I get the correct answer.

I assumed I was quite fluent in English, even in slangs, having seen a fair share of both American and British movies.

Now that I see the examples given, I think I would have mislabeled most of them too, even if I were highly motivated to label them.

Though it's normal for any language, it's very interesting how English is variable between dialects and time periods when it comes to slang. There are so many regional slangs of which I cannot understand all the nuances.

A few examples from this dataset, that I would not have labeled correctly:

- daaaaaamn girl! – mislabeled as ANGER

- [NAME] wept. – mislabeled as SADNESS

- [NAME] is bae, how dare you. – mislabeled as ANGER

And don't get me started on Australian/NZ slang. It's a completely different world.

It seems some representatives of the town of Nasu, where the stone is, suggest it should be put back whole [1].

> 「自然現象の可能性が高いので致し方ない。可能であれば元の形に近い状態に戻すことが理想ではないか」

Rough translation: It's likely this was a natural phenomenon, it can't be help. If possible, I think it would be ideal to put it back to its original shape.

[1] https://www.shimotsuke.co.jp/articles/-/561829

Never heard such a word as 料学.

Tuition is usually called 学費.

This is a very interesting project and I had a lot of fun playing with it.

A note though: all place names in Arabic are wrongly displayed.

Take Morocco for example. The Arabic name is المغرب.

It is wrongly displayed as something like ال م غ رب (letters are not attached together; I added zero-width space to force the letter to not be attached). And probably worse than that, the letters are displayed from left to right instead of right to left. You end up with something like ب رغ م ل ا.

This makes the native place names almost unreadable.

There probably is a similar directionality issue for other right-to-left languages (e.g. Hebrew), but I cannot read Hebrew enough to quickly check!

This post that deals with displaying Arabic appeared on HN some times ago and may be of help! [1]

[1] https://news.ycombinator.com/item?id=29544990

Epigno | Front-end Engineer, DevOps, Data Engineer | Tokyo / Sendai, Japan | Full-time, part-time or intern | REMOTE | https://epigno.jp

Epigno is a start-up that provides management, optimization and visualization (business intelligence) solutions to streamline hospital management. We provide consulting services and software solutions to solve hospital business needs.

Our team is entirely remote. We are hiring fast learners that finish their job on time and do not work overtime.

Tech stack: VueJS / Nuxt / Vuetify / Laravel (mainly)

We also have some projects with Python / Flask / Docker / Rust.

As we are still small, professional Japanese proficiency is highly preferred for full-time staff to reduce communication overhead with our team and our customers. For part-time positions Japanese proficiency is good to have. We hire people located in Japan only.

The position we are hiring for is an SSR application front-end engineer (with Nuxt & Vuetify), but we are flexible.

Depending on your skillset, you do not need to exactly fit in the above positions. In addition to front-end, back-end experience would as well be welcome, though not necessary. Generalist, full-stack engineers are welcome. Feel free to contact me for applying: malik(at)epigno(dot)jp

国籍問わず、日本語のできる日本在住のエンジニアはエピグノへ大歓迎です！

At a previous start-up, we did a similar mistake.

This was one of the worst day of my "engineer" life. I was very young and inexperienced at that time.

We were running a Ruby-On-Rails app with push notifications. We had an "on creating" life-cycle hook on a model recording an event, so that every time a new model was saved, a job sending a push notification (android or iPhone) to the appropriate user would the triggered. This would notify the users that the "event" was done.

The implementation was wrong. Instead of an "on creating" hook, the push notification logic was added in an "on saving" hook.

As the model was supposed to only ever be saved once (on creation), this worked for a while, and no-one ever realized. You now guess what's going to happen.

Then after some time, came the day when we needed to do some data migration. Easy right? The data-migration included updating some data in the the above model in question (all rows must be updated). We run a ruby script to update the model.

Everything was working in staging environment. So we release in production. The moment we release, we sent hundreds of push notifications to each of all our clients (including to our own phone, as we were using the service). Basically everyone was receiving as many push notifications as the number of "events" they completed until now.

Immediately, all the phones in the office (CEO's phone, sales rep, etc.) started to ring with complaints from customers asking what was going on. The CEO was as angry as you can imagine. But no time to be angry, as everyone needed to apologize and explain the situation to all our customers.

Basically the whole team was at fault for letting the problem slip through the code review. From then on, we improved code review process, and decided to include push-notifications in staging environment too.

Previous post on HN:

https://news.ycombinator.com/item?id=14476421

We are a small company and have been paying for GitLab's Bronze plan for about two years now.

We have about 5 devs, but the bulk of our GitLab users are non-technical (sales, customer support, etc.) who probably do not even know what git is. Those users are lurkers, but their input can be valuable and if possible I'd like them to be able to login onto GitLab.

Getting billed $228/users/year upfront is a harsh blow. I don't think I will ever be able to justify such cost to our CEO.

The way I see it now, we will renew our Bronze plan during the one-year grace period, while we are preparing the transition to another tool. Hopefully, we never really integrated our processes too much with GitLab, so we can transition whenever we need to.

If the "per user" subscription is to be that expensive, then I would suggest GitLab to provide a monthly subscription and/or a "per committer" subscription instead of a "per user" subscription.

> so much so it really felt like magic (there's a quote to be put here, which I can't find the author here. HN help me).

"Any sufficiently advanced technology is indistinguishable from magic."

Arthur C. Clarke

:)

I would not say that nuances were lost. At most, word usage and the way nuances are expressed have changed. People from the 1910s just happen to make use of many words that have fallen out of use for the people living in 2021.

Someone from 1910 would have a hard time understanding all the neologisms that were introduced after two world wars and decolonization until today.

For us from 2021, someone from 1912 uses words that are commonly found in written works from the same period (and after). This is why we feel it sounds like 'art'. Written words live way longer than spoken words.

Even today, common spoken French is very different from common written French.

True, they are not ubiquitous, but I have seen some on the highway.

They are usually very loud so you hear them before your see them.

Merry Christmas, Greg!

Thanks for all the hard work!

Having never been in the United States in the 80s or 90s, can some explain some background here?

It sounds very interesting but I cannot bring the pieces together.

I moved twice since I originally backed it.

Each time, I was able to update the shipping address on my account: https://shop.puri.sm/my-account/edit-address/

For good measure, I just checked and the currently set shipping address in indeed my current and latest address!

Driving through these roads just after they open around March/April is a blast. If you look enough, you can find places where you can actually climb on the snow walls and ski/hike on the snow slopes yourself. You may see a few trees whose apex is slightly protruding from the snow. It really feels like walking on the forest's canopy.

Apart from the road mentioned in this article, which I believe is the Tateyama Kurobe Alpine Route, you have the Shibu-touge (渋峠) road, which crosses the mountains between the Nagano and Gunma prefectures [1].

The Tateyama Kurobe Alpine Route does not allow private traffic on it year-round: it is a bus/taxi-only road. So if you are driving on your own, Shibu-touge is a great alternative. Route 299 going through the Yatsugatake (八ヶ岳) mountains is another alternative [2], although less fun in my opinion.

[1] https://goo.gl/maps/YbsoEgvih4oG3xvX9

[2] https://goo.gl/maps/nJB26wo6YzPVcawH9

> not sure if this is just formal language, or there is some important distinction between 注視 and 見て here.

Actually 注視 is as well the word that is used in the law that forbids people from watching the infotainment screen of a car while driving. 注視 means that you are looking at something, while exclusively concentrating your mind on this specific thing, not being aware of your surroundings.

Source:

Non-native Japanese speaker here, having lived in Japan for quite some time, and who took his driving license in Japan.

注視 definition in a Japanese dictionary: https://dictionary.goo.ne.jp/word/%E6%B3%A8%E8%A6%96/

Epigno | Front-end Engineer, DevOps, Data Engineer | Tokyo, Japan | Full-time, part-time or intern | 10% ONSITE / 90% REMOTE

Epigno is an start-up that provides management, optimization and visualization (business intelligence) solutions to streamline hospital management. We provide consulting services and software solutions to solve hospital business needs.

Our team is entirely remote. Team members living in the Tokyo area tend to gather once a week. We are hiring fast learners that finish their job on time and do not work overtime.

Tech stack: Laravel / VueJS / Nuxt / Vuetify / Python / Flask / Docker / Rust

As we are still small, professional Japanese proficiency is currently required for full-time staff to reduce communication overhead with our team and our customers. For part-time positions Japanese proficiency is good to have. We hire people located in Japan only.

We are mainly hiring for two positions:

* SSR application front-end engineer (Nuxt & Vuetify)

* Front-end engineer for the design and development of business intelligence tools

Depending on your skillset, you do not need to exactly fit in the above positions. In addition to front-end, back-end experience would as well be welcome, though not necessary. Generalist engineers are welcome. Feel free to contact me for applying: malik(at)epigno(dot)jp

国籍問わず、日本語のできる日本在住のエンジニアはエピグノへ大歓迎です！

https://www.epigno.jp/

I can relate. We use GitLab at our company.

I still think the merge request UI is great. Its main problems are its slowness and the fact that files with a long diff are collapsed. As the full merge request is quite slow, I will usually open the diff of each commit one by one, then put review comments as a "per commit" basis.