У меня на Lenovo P51 утилита обслуживания дисков Seagate SeaTools окирпичила SSD M.2 Samsung при попытке сканирования шин. Я сначала подумал, что это у меня кривые руки, но на всякий случай оформил репорт и через месяц в этот пост пришли отклики от других людей с такой же проблемой. Кто виноват и в чем проблема не сказали, но проблему пофиксили с выпуском новой версии SeaTools и новой прошивки для SSD Samsung
Не раскрыта следующая тема юридического плана. Я тут интересовался недавно, кто должен обслуживать мою батарею в случае когда в ней скопился воздушный пузырь (стояк горячий, а батарея холодная).
В общем, насколько я понял из написанного в интернетах, как только ваша батарея отчуждается от стояка различными клапанами и вентилями — батарея становится вашим личным имуществом и обслуживается за ваш личный счет. Если же батарея соединяется со стояком напрямую, то становится частью общей системы отопления, является общедомовым имуществом и обслуживается управляющей компанией.
По вашей же логике должно быть: знания устаревают -> меньше работников обладают «современными» знаниями -> меньше трудовое предложение -> зарплаты выше у тех кто идет в ногу с прогрессом
Бывают и исключения, но как известно, исключения только подтверждают правила.
Смысл этого выражения совершенно в другом и не соответствуют текущему контексту.
Вообще хороший программист — не тот, кого учили программированию в институте. Хороший программист как правило имеет хорошие оценки и по математике и по физике. И не потому что это нужно, а потому что хороший программист — это человек, который может почти непрерывно сидеть 4 часа уставившись в монитор и пытаясь разобраться в проблеме. Тот, который может входит в состояние «потока» и подолгу удерживаться в нем. Качество, которое присуще также ученым и исследователям. Качество, которое наблюдается далеко не у всех студентов.
Много приходится рефакторить/переделывать/править существующий (и работающий) код на Java.
Все чаще замечаю, что при правке многострочных stream-операций с лямбдами периодически приходится чесать репу: стоит немного что-то поправить и IDEA радостно подсвечивает все 10 строчек красным — поскольку информации о типах нигде нет и все выводится автоматически, то при потере малейшей части информации вывести тип не представляется возможным, а в явном виде он не указан.
Но лямбды реально позволяют избавится от лишних строчек при введении полноразмерных анонимных классов. А вот с var выгода что-то мне не кажется столь очевидной, поэтому никакого праздника не ожидаю.
Не претендую на полное описание всей ситуации — тут действительно много факторов. Это всего лишь попытка рационализировать поведение работодателя, то есть другими словами описать, что не он такой, а жизнь такая :)
Ну не факт, есть популярная теория мотивации (пирамида) Маслоу — про то, что мысль о том, чтобы выделиться мозгами приходит только тогда, когда есть чего пожрать, где поспать и что одеть, и все в безопасности и с уверенностью что так будет и завтра.
Когда же есть нечего, а жить часто только вместе родителями — то тут как-то не до высоких материй.
Раньше старались выделиться мозгами, опытом или навыками. Сейчас — зарплатой, цветом губной помады, собственным телом, комментарии к статьям пишутся без запятых и на сленге, а не языке…
Мы в каких-то разных странах видимо выросли, потому как в моей люди все также хвастались чешскими гарнитурами, выхваченными по случаю сапогами, хрусталем и блатом в магазинах.
Отличный комментарий кстати, поставил бы даже два плюса. Но я несколько не согласен по деталям.
Предположим есть два программиста A и B с одинаковой квалификацией и производительностью и выполняющих одинаковый объем работ: однако программист A получает меньше программиста B.
Рассмотрим ситуацию со стороны работодателя:
— если оба программиста не знают зарплату друг друга: с точки зрения работодателя пусть это будет нулевая ситуация
— если программист B знает зарплату программиста A (меньшую чем у него): то B получит небольшой буст производительности, однако мотивация вряд ли продержится долго так как деньги сами по себе несильно мотивируют. В редких случаях его будет мучать совесть и мы получим деградацию, но такой случай рассматривать не будем. Итого: +2
— если программист A знает зарплату программиста B (большую чем у него): чувство несправедливости начнет понижать производительность и лояльность A, скорее всего со временем это чувство будет еще больше усиливаться, а производительность понижаться. Итого: -4 (числа я взял с потолка)
— если оба знают зарплату друга: скорее всего можно рассматривать эти два процесса как независимые и просто просуммировать итоги. Но вполне возможно они еще либо поругаются, либо A начнет выдвигать претензии, а B будет неловко и итог деградирует еще сильнее. Итого: -3
В итоге выходит так, что неплохо было бы, чтобы более высоко-оплачиваемые программисты знали зарплату менее оплачиваемых (и молчали о своей). Но тут возникает интересная ситуация: если я не знаю зарплату коллеги, это значит что он точно получает больше чем я.
В итоге с точки зрения работодателя лучше помалкивать и также заставить помалкивать работников. Ну или действительно ввести публичные разряды/градации и в рамках одного разряда платить всем одинаково. Однако тут тоже есть нюанс, объективная потребность в деньгах у женатого с тремя детьми и холостого одиночки разная — у первого свободных денег скорее всего нет, а второй может позволить себе путешествовать либо покупать предметы роскоши. «Кого это волнует, работают же они одинаково» — скажете вы, и тоже будете правы.
В целом, лично я не вижу особой трагедии в незнании — поскольку свою зарплату можно регулярно сравнивать с зарплатой в других компаниях через прохождение собеседований :)
Сперва мы изобрели «велосипед» и сделали таблицу MUTEX, которую блокировали на доли секунды на время расчета значения счетчика. Под большой нагрузкой стали ловить dead block. Потом воспользовались пакетом DBMS_LOCK и создали блокировку куска кода, который работал со счетчиком.
вообще существуют оптимистические блокировки и конструкции типа:
UPDATE counters SET value = value + 1 WHERE name = :name AND value := old_value
ну и в 21м веке уже есть in-memory решения которые делают такое мгновенно, атомарно и с персистентностью
Обычно типовая задача — это нарезка закачанной пользователем картинки сразу в несколько (2..8) различных типоразмеров. То есть закачивать исходную картинку мы будем только один раз, а нарезать — несколько.
Еще бы сравнить GPU-based методами, а так полагаю там много времени уходит на копирование данных в памяти, но можно было бы сравнить уменьшение сразу пачки картинок в целый набор типоразмеров.
До перехода на Git мы пользовались Source Depot и код был распределен по 40 с лишним репозиториям
Не очень понятно почему бы не продолжать делать также — разбить на изолированные независимые модули и работать с ними также независимо. Зачем хранить исходники всей системы (видимо даже солитер там) в одном репозитории?
P.S.: Коллекцию можно ещё больше ускорить за счёт использования красно-чёрного дерева вместо бинарного.
Красно-черное дерево — это реализация сбалансированного бинарного дерева поиска.
. При выборе TreeSet или TreeMap мы будем иметь O(log(n)) для вставки и поиска, но для поиска и удаления минимального будем иметь всего лишь O(1).
В стандартнах классах java.util.TreeMap#getFirstEntry работает за O(log n)
Вам на самом деле нужно не дерево, а min-heap. И прикрутить к нему HashMap который будет запоминать индекс в Heap для возможности работы с произвольным элементом.
Добавлю к последнему абзацу то, что некие «сакральные» знания, якобы доступные исключительно людям с 20-летним опытом часто не нужны по причине того, что для 95% IT-проектов в России реально достаточно just good enough качество (особенно это касается коротких проектов и мелких бюджетов). То есть нужно просто знать технологию X и молча без зауми херачить проект Y.
Смена профессии на менеджера тоже не серебрянная пуля — в связи с более низкой ликвидностью среднего сферического менеджера относительно разработчика такой же геометрии.
Самая большая проблема программистов людей при возрастании пробега — прогрессирующее занудство, исчезающая самоирония и старческая слезливость. В качестве профилактики могу только предложить витамины, полистать луркмуар и послушать группу «Кровосток».
В общем, насколько я понял из написанного в интернетах, как только ваша батарея отчуждается от стояка различными клапанами и вентилями — батарея становится вашим личным имуществом и обслуживается за ваш личный счет. Если же батарея соединяется со стояком напрямую, то становится частью общей системы отопления, является общедомовым имуществом и обслуживается управляющей компанией.
Поправьте меня если неправ.
По вашей же логике должно быть: знания устаревают -> меньше работников обладают «современными» знаниями -> меньше трудовое предложение -> зарплаты выше у тех кто идет в ногу с прогрессом
Смысл этого выражения совершенно в другом и не соответствуют текущему контексту.
Вообще хороший программист — не тот, кого учили программированию в институте. Хороший программист как правило имеет хорошие оценки и по математике и по физике. И не потому что это нужно, а потому что хороший программист — это человек, который может почти непрерывно сидеть 4 часа уставившись в монитор и пытаясь разобраться в проблеме. Тот, который может входит в состояние «потока» и подолгу удерживаться в нем. Качество, которое присуще также ученым и исследователям. Качество, которое наблюдается далеко не у всех студентов.
Все чаще замечаю, что при правке многострочных stream-операций с лямбдами периодически приходится чесать репу: стоит немного что-то поправить и IDEA радостно подсвечивает все 10 строчек красным — поскольку информации о типах нигде нет и все выводится автоматически, то при потере малейшей части информации вывести тип не представляется возможным, а в явном виде он не указан.
Но лямбды реально позволяют избавится от лишних строчек при введении полноразмерных анонимных классов. А вот с var выгода что-то мне не кажется столь очевидной, поэтому никакого праздника не ожидаю.
Когда же есть нечего, а жить часто только вместе родителями — то тут как-то не до высоких материй.
Мы в каких-то разных странах видимо выросли, потому как в моей люди все также хвастались чешскими гарнитурами, выхваченными по случаю сапогами, хрусталем и блатом в магазинах.
Предположим есть два программиста A и B с одинаковой квалификацией и производительностью и выполняющих одинаковый объем работ: однако программист A получает меньше программиста B.
Рассмотрим ситуацию со стороны работодателя:
— если оба программиста не знают зарплату друг друга: с точки зрения работодателя пусть это будет нулевая ситуация
— если программист B знает зарплату программиста A (меньшую чем у него): то B получит небольшой буст производительности, однако мотивация вряд ли продержится долго так как деньги сами по себе несильно мотивируют. В редких случаях его будет мучать совесть и мы получим деградацию, но такой случай рассматривать не будем. Итого: +2
— если программист A знает зарплату программиста B (большую чем у него): чувство несправедливости начнет понижать производительность и лояльность A, скорее всего со временем это чувство будет еще больше усиливаться, а производительность понижаться. Итого: -4 (числа я взял с потолка)
— если оба знают зарплату друга: скорее всего можно рассматривать эти два процесса как независимые и просто просуммировать итоги. Но вполне возможно они еще либо поругаются, либо A начнет выдвигать претензии, а B будет неловко и итог деградирует еще сильнее. Итого: -3
В итоге выходит так, что неплохо было бы, чтобы более высоко-оплачиваемые программисты знали зарплату менее оплачиваемых (и молчали о своей). Но тут возникает интересная ситуация: если я не знаю зарплату коллеги, это значит что он точно получает больше чем я.
В итоге с точки зрения работодателя лучше помалкивать и также заставить помалкивать работников. Ну или действительно ввести публичные разряды/градации и в рамках одного разряда платить всем одинаково. Однако тут тоже есть нюанс, объективная потребность в деньгах у женатого с тремя детьми и холостого одиночки разная — у первого свободных денег скорее всего нет, а второй может позволить себе путешествовать либо покупать предметы роскоши. «Кого это волнует, работают же они одинаково» — скажете вы, и тоже будете правы.
В целом, лично я не вижу особой трагедии в незнании — поскольку свою зарплату можно регулярно сравнивать с зарплатой в других компаниях через прохождение собеседований :)
вообще существуют оптимистические блокировки и конструкции типа:
ну и в 21м веке уже есть in-memory решения которые делают такое мгновенно, атомарно и с персистентностью
А вообще в курсе, что в 2017-м к любому смартфону и планшету можно подключить клавиатуру по bluetooth?
Не очень понятно почему бы не продолжать делать также — разбить на изолированные независимые модули и работать с ними также независимо. Зачем хранить исходники всей системы (видимо даже солитер там) в одном репозитории?
Красно-черное дерево — это реализация сбалансированного бинарного дерева поиска.
В стандартнах классах java.util.TreeMap#getFirstEntry работает за O(log n)
Вам на самом деле нужно не дерево, а min-heap. И прикрутить к нему HashMap который будет запоминать индекс в Heap для возможности работы с произвольным элементом.
Смена профессии на менеджера тоже не серебрянная пуля — в связи с более низкой ликвидностью среднего сферического менеджера относительно разработчика такой же геометрии.
программистовлюдей при возрастании пробега — прогрессирующее занудство, исчезающая самоирония и старческая слезливость. В качестве профилактики могу только предложить витамины, полистать луркмуар и послушать группу «Кровосток».Колян, 40 лет.
/usr/local — хранит локально собранное ПО, которое не управляется пакетным менеджером и не входит в первоначальный состав системы.
/opt — обычно для самодостаточного ПО, которое упаковано не по файловому стандарту *nix. Я например туда Oracle JDK всегда распаковываю.