Блог*
رفتن به کانال در Telegram
Блог со звёздочкой. Много репостов, немножко программирования. Небольшое прикольное комьюнити: @decltype_chat_ptr_t Автор: @insert_reference_here
نمایش بیشتر1 928
مشترکین
اطلاعاتی وجود ندارد24 ساعت
+37 روز
+330 روز
آرشیو پست ها
1 926
#prog
yuml.me — сайт для рисования UML-диаграмм. Диаграммы описываются в URL.
Пример
(thanks @FindYouByUsernameAndContactYou)
1 926
Почему у "мужских" продуктов бытовой химии — гелей для душа, шампуней, дезодорантов — такие противные запахи?
1 926
#prog #article
A Cursed Bug
When you start dealing with large distributed systems, you see a lot of intermittent weird bugs, and it’s basically inevitable that you’ll never track down or diagnose all of them. But it turns out that sometimes, with a bit of luck and persistence, even the hairiest ones can sometimes be tracked down.
1 926
#soc #article
Not Rocket Science (Meeting Edition)
You know what else feels like a waste of collective time? When the CI is broken due to some failure which was introduced but not checked in PR testing, preventing people from landing their patches. In the context of CI, Graydon Hoare has this fun blog post from 2014: “Not Rocket Science” rule of software engineering. It proposes the following:
The Not Rocket Science Rule Of Software Engineering
Automatically maintain a repository of code that always passes all the tests
You can read the post for details, but my takeaway from it is that it is intended to save collective time at the expense of individual time. Also, it’s not a particularly genius idea; it requires some setup and work but it should be doable for many teams.
I’d like to propose a similar rule for meetings.
The Not Rocket Science Rule of Meetings
Planned meetings of three or more people should be accompanied by shared, written and persistent meeting notes, consisting of an agenda before the meeting, and added minutes after the meeting.
1 926
Experience Report: 6 months of Go
Later, while I was doing background research around previous posts on Go, and people’s responses to them, one comment stood out to me:
> I think Go follows the Worse Is Better principle. Which could explain why simplicity was chosen above correctness and completeness.
<...>
One of the things I realized that I was refusing to internalize was that the Go team prioritizes keeping implementation complexity down a LOT more than folk implementing other mainstream languages that I know of.
To half of my brain, this statement seems absurd at face value. That half indignantly insists, “Of course, complexity should be moved into the language as much as possible if it makes things better for language users! There are many more language users than implementors!” I suspect this is partly an outcome of and partly a cause for why I ended up working on Swift.
<...>
At the same time, I think for me, the MIT approach is so much more closer to how I think about software design and correctness, that even though I can “get” the New Jersey style in the abstract, it’s very difficult for me to internalize it. There is a serious cognitive effort that is needed to overcome the impedance mismatch between a conception of “how things ought to work” and the reality of “how things actually work.”
1 926
Вышел из поезда.
Прошёл через турникет.
Подумал, что чего-то не хватает.
Понял, что не хватает зонта.
Решил, что оставил зонт в поезде, то есть фактически потерял.
Слегка расстроился и решил купить новый.
Спустя мгновение понял, что держу зонт под подмышкой.
1 926
Repost from Питерач • Новости Питера
🤔 На экономическом форуме РБК разместил интересный слоган-ребус.
Про бизнес, конечно же.
