#реклама #підтримуємозсу

Приєднуйся до NIX Coding Challenge!

Здається, ми стали забувати, за що полюбляємо програмування… Запрошуємо тебе відчути кайф від невпинного кодинґу 😉

Покажи, на що ти здатний, на NIX Coding Challenge!

Коли: 15 жовтня, з 11:00 до 18:15
Де: онлайн

На тебе чекає алгоритмічних 5 задач. Кожна наступна буде складнішою за попередню. Але ми віримо у твої сили, так само, як і в Перемогу України!

Ти прокачаєш навички логічного мислення і зможеш отримати приз — сертифікат на купівлю ґаджетів! Свій результат дізнаєшся того ж дня у Telegram.

Для участі необхідно:
🔹 мати практичний досвід в IT від 1,5 року;
🔹 уміти програмувати будь-якою мовою;
🔹 знати, як розв'язувати алгоритмічні задачі.

До початку змагання встанови на ноутбук чи комп'ютер інтерпретатор або компілятор тієї мови, якою будеш кодити.

Приймай Ніксовий челендж уже зараз — реєструйся за посиланням!

Есть офигенный термин, «Эмерджентность». Это такое свойство из теории систем, которое показывает, что у некой сущности есть свойства, которых нет у её отдельно взятых компонентов.

Например, если взять отдельные атомы, то каждый из них не будет обладать свойствами, которыми будет обладать молекула, созданная из этих атомов. Или, более глобальное, вроде кирпичи и доски не обладают способностью прятать людей от дождя и холода, а вместе, в виде дома, вполне себе могут. Ну вы идею поняли, в общем.

Там, в этой теории систем, скорее рассказывается о физическом и биологическом уровне абстракции. Ещё там много внимания уделяется переходу от неживого к живому, мол эмерджентность, как свойство хорошо объясняет появление жизни из неживых материалов, но это тема отдельного поста (ставьте ⚡️, если хотите об этом пост).

А вот, что круто, что эмерджентность в коде — это невероятно крутой способ сказать насколько ваш код хорош. Если имплементировав фичу А и фичу Б, пользователь получит нечто большее, чем две фичи, то с уверенностью можно сказать, что ваш код хорош.

Ладно, кит тоже засчитывается за молнию :-)

Современный человек использует свой смартфон лишь на 10% от его потенциала.

Разыскивается веб-технолог для внешне простой, но со своими нюансами лендингом. Минимум js, максимум a11y, включая поддержку rtl. Я бы оценил, что там на пару дней плотной работы, но это не точно. Будет шикарно, если прям в проекте с рельсами работа будет сделана.

За подробностями в личку (@aratak). Спасибо.

Самая проклятая профдеформация у разработчиков — умение делать выводы по неполным данным.

С одной стороны это необходимо и, вроде бы, это позволяет строить полноценные системы из обрывочных и несистемных примерах и это чуть ли не основа профессии. А с другой — эта же деформация сознания заставляет делать выводы там, где буквально нифига не знаешь и надо бы сначала долго разбираться. Но нет — дедуктивным способом Шерлокам уже все и так ясно.

Особенно это заметно, когда дело доходит до чужого кода или проекта. Использовали библиотеку А, а не Б? Они определённо совершили глупость. Написали свой oAuth-сервер? Дураки, есть же готовые. Используют рельсы для лендинга? Высшей степени некомпетентность не иначе.

Нужно ли винить в этом разработчиков? Однозначно нет, ведь без такой профдеформации не будет и разработчика. Задавать больше вопросов и не делать выводов, если этого не требуется.

Маленькие пулл реквесты и рабочий мастер.

Ни у кого не вызывает сомнения, что пулл реквесты должны быть чем меньше, тем лучше. Типа, удобнее делать ревью, искать ошибки и следить за прогрессом. Это да.

С другой стороны, есть вполне здравое правило постоянной работоспособности мастер-ветки. Типа, деплой в любой момент, тесты проходят и баги ищутся проще, новые ветки все начинают с рабочего состояния и всякое такое.

И проблема в том, что эти два правила вступают в логическое противоречие, когда маленький пулл реквест не сделает фичу целиком, а большой тяжело отсматривать. Как результат, в головах разработчиков побеждает правило работоспособного мастера и пулл реквесты на пару тыщ строк считается вынужденным злом.

А фишка в том, что в мастере не должно быть законченное целое количество фич, а мастер просто должен быть рабочим.

Нормальным будет сделать пулл реквест, в котором появляется абстрактный класс, а реализация — отдельными пулл реквестами. Если новые css стили вместе с описаниием и примерами появятся в одном пулл реквесте, а поголовноое приименение этих стилей — в другом.

В общем, правила такие:
1. Пулл реквест должен быть как можно меньше. Если пулл реквест можно разбить на два отдельных — бейте.
2. В мастере должны проходить все тесты. Ну, или мастер должен технически запускаться и не падать, если вдруг у вас нет тестов.
3. Вполне допустимо в пулл реквесте сделать код, который не используется по назначению прям в этом пулл реквесте, а будет использоваться в следующих. И убедить коллег в работоспособности этого кода проще всего с помощью тестов. Или пистолета.
4. Технические изменения пулл реквеста должны описываться одним предложением. Не «сделал фичу», а «поменял сигнатуру метода» или «обновил библиотеку и зависимости». Человеческие описания оставьте задачам, а в пулл реквестах говорите о коде.

#перечитываяэкстраполяцию

В режиме жесткой экономии электричества в стране вспомнился экономический принцип под названием «Равновесие Нэша» и тут эта нехватка электричества — наглядный пример этого принципа.

Правила такие. Электричества хватит на всех и свет выключать не будут, если все участники договора будут экономить. И наоборот, начнутся веерные отключения света, если будет перегрузка электростанций. Казалось бы, самой выгодной стратегией будет экономить электричество по-полной и отказаться от необязательных электроприборов. Но вот если все вокруг будут жёстко экономить, то, казалось бы, включить микроволновку на минуточку или электрочайник вскипятить — не будет большой бедой, верно? Среди всех вокруг, кто экономит, весьма неплохо оказаться в привелигированном положении и не экономить.

Проблема в том, что ровно такой стратеги могут (и будут) придерживаться вообще все вокруг, тем самым перегрузить сеть так, чтобы вообще остаться без электричества. Конечно, экономить, когда сосед охамел вкрай и включил вообще всё, что мог, возмутительно неправильно. Хочется тоже пользоваться благами цивилизации, как этот гад по соседству. Это решение и приведёт к фиаско.

Вместо этого решением будет не повторять за этим «соседом», а найти способы заставить его соблюдать общие правила. В масштабах больших экономик это решается всякими комиссиями и контроллирующими органами, но принципиально это вопрос не решает.

Художественное красивое описание этого принципа есть в байопике «A Beautiful Mind» 2001 года. Только там про четырёх брюнеток и блондинку было.

​​#реклама

На звязку команда G5 Games. Запршуємо вас на безкоштовний благодійний стрім для IT-фахівців всіх рівнів.

Наша мета — зібрати 250 000 грн, щоб допомогти одному з сіл Куп'янського району підготуватися до зими.

Вас очікує:
✅ 12-годинна трансляція в режимі нон-стоп.
✅ Доповіді від спікерів G5 Games-художників, розробників, локалізаторів, продюсерів і рекрутерів.
✅ Відповіді на запитання слухачів.
✅ Благодійна гра “Що? Де? Коли?”.
✅ Розіграш призів.
✅ Бонус: спеціальні гості, про яких ми розповімо пізніше.

Від нас — гідний контент, від вас — донати для допомоги району.

✏️Коли?
26 листопада з 9:00 до 21:00.

✏️Як взяти участь?
Підписуйтесь на наш телеграм-канал, щоб не пропустити важливі новини, там буде посилання на стрім:

https://www.tgoop.com/+v0mts3U_k6pjZTQy

Разом допоможемо Куп'янському району підготуватися до зими!

Привет. Зайдите, пожалуйста, нажмите upvote. Ну, и пользуйтесь, кому надо, это бесплатно. Спасибо.

https://www.producthunt.com/posts/tasks-for-slack

Недавно на канале «Клятий Раціоналіст» я услышал, что оказывается пирамиды Маслоу не существует. Ну, там не всё так однозначно, конечно, но смысл в том, что это весьма условное понятие, с кучей контрпримеров и опровержений. И вообще это не пирамида, а ступеньки.

Но вот фишка, что на себе я весьма ощутимо прочувствовал всю мощь этой несостоятельной теории. Будучи под оккупацией в начале года вот совершенно не думалось о этих ваших стартапах, статических языках программирования и управлении проектами. Весь день уходил на то, чтобы найти что пожрать и попить и не умереть от шальной пули. После эвакуации стало немного проще и речь зашла об социальных связях и взаимоотношениях. Уже после налаживания связей, можно было что-то говорить о более высоких материях. Сейчас, когда свет или вода может отсутствовать часов по двадцать, тоже жизненные потребности и требования к окружению сильно снизились и радоваться можно уже даже просто горячему душу или работающему интернету. И практические навыки мой мозг ценит сейчас совсем другие. Вроде умения паять паяльником, разбираться в DC-DC инвенторах, быстро в уме переводить ватт-часы в ампер-часы и наоборот.

Короче, это я так высокопарно оправдываюсь почему тут затишье в «Экстраполяции». Потому что я скатился на пару ступеней пирамиды Маслоу вниз и вещаю сейчас отсюда.

​​Я думаю, совершенно никто не будет спорить с тем утверждением, что порно с несовершеннолетними — это то, чего существовать не должно в принципе и безопеляционно. Ни при каких условиях. В первую очередь это не должно существовать не потому, что это кто-то увидит, а потому, что это нужно как-то и с кем-то снимать.

В то же время, современные нейросети уже научились генерировать видеоконтент паршивого качества и картинки довольно приличного. Значит скоро и видео приличного качества тоже будет. А в видео этом то, чего никогда не было и не существовало. Так сказать, додумать, усреднить и подменить.

Если можно сгенерировать самурая Рона Уизли, то можно вообще всё, что угодно. Очень интересно, какой у этого будет юридический и правовой подход в ближайшем будущем.

Чем клево число Пи? Во-первых и основных это иррациональность и трансцендентность этого числа. Технически это означает, что π нельзя представить никаким другим числом. В том смысле, что его нельзя предствить в виде корня какого-то другого многочлена с целыми коэффициентами и нельзя представить в виде дроби простых чисел (m/n). Число π бесконечно и непериодично в десятичном представлении. А это значит, что теоретически в числе π найдется любая другая подпоследовательность. Нужно только хорошо ее поискать.

А совсем недавно, по меркам открытий, нашли формулу, которая позволяет вычислять любой знак числа пи без вычисления предыдущих, и эта формула относительно проста. И тут понеслось.

Раз мы знаем, что в числе π спрятана любая последовательность чисел и по указанному смещению и длине мы с легкостью можем вычислить эту подпоследовательность, то можно «спрятать» в числе π любой файл, программу или секретный код, главное, чтобы он выражался через числовую последовательность. В итоге в числе π уже есть «Война и мир», исходный код всех операционных систем, все фотографии, которые все человечество когда-либо сделало или сделает. Нужно просто хорошенечко поискать.

Конечно же, искать подпоследовательность хотя бы в 50 мегабайт очень долго и тяжело, но вот после того, как найти такую подпоследовательность, этот файл можно выписать себе на листик в виде смещения в π и длинне подпоследовательности. Сжатие в 100%! Никаким «зипам» и «рарам» это и не снилось!

К сожалению не все так радужно, как хотелось бы. И дело не в том, что такую подпоследовательность очень долго искать -- закон Мура говорит нам, что искать таки можно и в будущем будет это легко. Дело в том, что такое смещение вполне вероятно будет занимать больше места, чем сам файл.

Ну ничего, давайте файл разобъем на более мелкие кусочки, скажем в 640 килобайт, а их уже будем прятать в π. Тогда на смещение в 640КиБ нам нужно будет потратить, скажем, 2Киб, и тогда сжатие будет не 100%, а ~99%. Звучит более реалистично и вполне реализуемо. Более того, уже даже файловая система такая есть, основанная на этом незамысловатом принципе. Работает, конечно, медленно, но работает.

https://github.com/philipl/pifs

#перечитываяэкстраполяцию

На хамбл-бамбл продают пак книг по функциональному программированию. За $18 можно урвать неплохую коллекцию книг. Хорошее времяпрепровождение, когда света нет, а читалка заряжена.

https://www.humblebundle.com/books/functional-programming-pragmatic-programmers-books

В школе и университете грамоты мне казались чем-то несущественным и вообще не стоящим никакого внимания. Но тогда они и правда были несущественными. Сейчас наоборот — это повод для гордости.

Спасибо всем, кто вместе со мной делает эти добрые дела. Я далеко не всё пишу в канал из того, что мы делаем, но если кто-то хочет присоединиться к нам в этом нелегком деле — ссылка всегда есть в описании к каналу. Спасибо.

Критерий хорошего кода.

Основным показателем хорошо структурированного и написанного кода является его способность заменять библиотки. Совсем вырожденный сферическо-единорожный случай, которого не существует в природе — это когда был PostgreSQL, а заменили на MySQL с минимальным изменением кода. Понятное дело, такого не бывает, конечно, но критерий хорошо написанного кода демострирует хорошо. Более частый и менее совоглобусовый случай — обновление мажорных версий библиотек и языков программирования.

Чем проще и чем с меньшими неожиданностями сталкивается разработчик при обновлении библиотек, тем лучше и качественней кодовая база. Конечно, это вовсе не означает, что если вы просто написали npm update и у вас всё завелось с полпинка, то у вас идеальный код, вовсе нет. Скорее это повышает уверенность или вероятность того, что код хороший.

Не то, чтобы прям «критерий», но больше некая лакмусовая бумажка, получается.

Каждый разработчик без проблем и промедлений может сказать хороший или плохой вот этот вот кусок кода. Вот прям посмотрит и сразу скажет. А уж потом, после тщательного анализа и ковырянии сможет хоть как-то внятно сформулировать почему же код на самом деле говно.

Это всё потому, что такие критерии вторичны. Код сначала говно, а уже потом говно по какой-то конкретной причине.

Часть проблем, которые приписывают айтишникам, свойственны всем людям любых профессий. Одно из самых очевидных и легко идентифицируемых проблем — это желание переделать все с нуля. И с программированием тут дела обстоят точно так же, как и, скажем, с сантехникой.

Если в нашей отрасли эксперта, который предлагает переписать все на другом языке или фреймворке пытаются как-то образумить, слушают его и допускают его гипотетическую правоту, то сантехника со взглядами «Петрович, тут всю систему менять нужно» и «предыдущий сантехник был идиот, сейчас все переделаем с нуля» считают неквалифицированным и работу поручать не хотят.

Конечно же, чем опытней специалист, тем завуалированней это самое его «давайте все переделаем с нуля». С опытом приходят изыски вроде «концепция изначально была выбрана неверно», «устранить ошибку лучше сразу фундаментально» и «используемые инструменты устарели и новый фреймворк лишён недостатоков из коробки». Но это все то же старое доброе «тут уже ничего не справить, жги».

Конечно же, есть ситуации когда действительно нужно все переписать и действительно исправлять выйдет дороже, но это стоит считать крайней мерой, когда все остальное уже перепробовано и отвергнуто. Такое предложение хорошо бы слышать от человека, который знаком с системой, знает все исторические вехи и понимает почему было принято то или иное решение в прошлом.

Предложение переписать все нахрен ни в каких случаях недопустимо от человека только что присоединившегося к проекту.

#перечитываяэкстраполяцию

Эй, новички в программировании, вот вам лайфхак как правильнее всего научиться программировать или познакомится с новым языком и фреймворком.

Забейте на код и научитесь писать тесты.

Увидели новый фреймворк? «Как тут у вас тесты пишутся?» — должен быть первый и самый главный вопрос к документации. Новый язык или библиотека начинать изучаться могут только из секции «tests», а уж потом можно переходить к секции «how to install».

Вы всё-равно будете по тысячу раз в минуту проверять работоспособность написанного кода. Вы будете экспериментировать с новыми конструкциями, концепциями и структурами. Делайте это сразу автотестами.