Это циничная, клиническая коллекция того, чему я научился за 30 лет работы в разработке программного обеспечения. Повторюсь, некоторые вещи весьма циничны, а остальное — результат долгих наблюдений на разных местах работы.

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

Возможно, вы задумаетесь о чём-то важном, читая этот список.

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

О чём нужно помнить, чтобы жизнь была удобнее и полноценнее?

Недавно вышла статья, которая неплохо показывает тенденцию в машинном обучении последних лет. Если коротко: число стартапов в области машинного обучения в последние два года резко упало.


Ну что. Разберём «лопнул ли пузырь», «как дальше жить» и поговорим откуда вообще такая загогулина.

Привет, меня зовут Дмитрий, мне 35 лет. Раньше я часто слышал, что программист — профессия для молодых. Тем не менее прошлым летом я получил приглашение в Яндекс и перебрался работать в Москву.

В этой статье я хотел бы затронуть вопрос, который не раз обсуждался на Хабре: насколько реально быть программистом после 35–40 лет? Не ведущим архитектором, не тимлидом, не менеджером проекта, а именно программистом? Я не согласен с мнением, что программирование — это удел молодых. Считаю его вредным и сейчас расскажу почему.

Существует несколько доводов, на которые опирается этот миф. Давайте-ка их подробно рассмотрим.

Учиться лучше на чужих ошибках и мысленно благодарить тех, кто такую возможность предоставляет. Под катом несколько типичных примеров того, чего не стоит делать на Хабре. И что делать в случае, если сливают.

This article is also available in English

Из-за массового выпуска смартфонов без аудиоразъема 3.5 мм беспроводные Bluetooth-наушники для многих стали основным способом прослушивания музыки и общения в режиме гарнитуры.
Производители беспроводных устройств не всегда пишут подробные характеристики товара, а статьи о Bluetooth-аудио в интернете противоречивы, местами некорректны, не рассказывают о всех особенностях, и часто копируют одну и ту же не соответствующую действительности информацию.
Попробуем разобраться с протоколом, возможностями Bluetooth-стеков ОС, наушников и колонок, Bluetooth-кодеков для музыки и речи, выясним, что влияет на качество передаваемого звука и задержку, научимся собирать и декодировать информацию о поддерживаемых кодеках и других возможностях устройств.

TL;DR:

• SBC — нормальный кодек
• У наушников есть свой эквалайзер и пост-процессинг на каждый кодек отдельно
• aptX не настолько хорош, как о нём говорят рекламные анонсы
• LDAC — маркетинговое фуфло
• Качество звука в режиме разговора всё ещё низкое
• В браузер можно встроить аудиоэнкодеры на C, скомпилировав в WebAssembly через emscripten, и они не будут особо тормозить.

Это ответ на неожиданную статью на Хабре психиатра с тридцатипятилетним стажем Александра Геннадьевича Данилина, также довольно известного youtube влогера. До его статьи на Хабре я не обращал на его творчество внимания, как выяснилось, зря.

Но сначала короткое предисловие.

Для меня психиатрия болезненная и личная история. К сожалению, это очень специфичная область медицины, в которой эзотерика и мракобесие очень успешно сопротивляются научному знанию. Дело в том, что доказательной медицине вообще чуть более тридцати лет. И медицинское сообщество только сейчас с кровавой рвотой исторгает из себя всякую гомеопатию. В психиатрии же ввиду объективных факторов процесс идет тяжелее всего. Эта область все еще является заповедником для шарлатанов, невежд, идиотов и фриков от науки со своими особыми трактовками и истинами, почерпнутыми из “философских размышлений”. Революция в нейронауках, в частности, в психологии и психиатрии происходит прямо сейчас. Увы, не для всех.
К не слишком компетентным, но придерживающимся стандартных программ и методик лечения психиатрам, я отношусь довольно холодно. Тем не менее, они делают то, чему их научили. Как правило, это позволяет им вывести пациента из острого психотического состояния. Ну, а дальше у него по крайней мере будет шанс. Возможно, в будущем разработают лучшие методики, будут лучше лечить. Но вот фрики, выковыривающие свои антинаучные гипотезы из известного места и применяющие их при лечении тяжелых пациентов, вызывают во мне острое нестерпимое желание жечь, жечь, жечь в драконьем пламени. Я слишком хорошо знаю, к чему приводит их невежество.

Я был в этом аду, я в нем горел.

Итак, за примерно год (май 2017 — февраль 2018) я, программист C++, нашел-таки работу в Европе. Я десятки раз откликался на вакансии в Англии, Ирландии, Швеции, Нидерландах и даже в Португалии. Я раз двадцать беседовал по телефону, скайпу и прочим системам видео связи с рекрутерами, и несколько меньше — с техническими специалистами. Я ездил в Осло, в Эйндховен и три раза в Лондон на финальные интервью. Все это подробно описано здесь. В итоге я получил один оффер и принял его.



Оффер этот был из Нидерландов. Работодателям в этой стране относительно просто пригласить работника из-за рубежа (не из Евросоюза), поэтому бюрократической волокиты немного, а сам процесс оформления занимает всего несколько месяцев.

Но всегда можно самому себе создать сложности. Что я и сделал, чем затянул свой переезд еще на месяц. Если интересно почитать о хлопотах (нет, не сильно приятных) связанных с переездом IT семьи в Западную Европу — добро пожаловать под кат.

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


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

Привет, %username%

Да, я знаю, заголовок избитый и в гугле есть овер 9000 ссылок, в которых описываются страшные яды и рассказываются ужастики.

Но я не хочу перечислять то же самое. Я не хочу меряться дозами LD₅₀ и претендовать на оригинальность.

Я хочу написать про те яды, с которыми ты, %username%, имеешь большой риск столкнуться каждый день. И которые не так просты, как их ближайшие собратья.

Врага надо знать в лицо. И надеюсь — будет интересно. А если окажется интересно — то возможно, что и осилишь вторую часть.

Итак — моя смертельная десятка!

Приветствую всех. Сегодня расскажу вам как я проходил собеседования в Москве на позицию .Net Developer. Усиленно готовился к собеседованиям месяц, целыми днями сидел и смотрел вопросы и пытался отвечать на них, а также читал книжки по С#. В статье привожу интересные задачки и вопросы, которые мне задавали в разных компаниях в Москве. Заранее скажу, что я попал в ту компанию, в которую хотел. Я прошел 4 собеседования в этой компании и меня наконец то взяли! Много статей было прочитано в частности здесь и надеюсь, что эту статью тоже будут читать начинающие Net разработчики и спрашивать все в комментариях.

Кому интересна тема прохождения собеседований, прошу под кат!

Любой советский школьник, собиравший подобную схему знал, что без заземления — никак.

Нынешнее поколение Z, взращенное айфонами, сомневается даже в необходимости антенн!

Эта статья показывает важность и необходимость двух данных элементов в условиях слабого сигнала.

У истинных связистов методика используемая далее вызовет весьма неоднозначные чувства(я предупредил), остальным можно и почитать.

Тема касается прежде всего проблемы GSM-связи, и разбирается на примере SIM800L, используемого многими в своих конструкциях.

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

Многими людьми радиация представляется, как нечто «заразное»: считается, что если что-то подверглось воздействию радиации, оно само становится ее источником. Данные представления имеют свое рациональное зерно, но способность радиации «переходить» на облучаемые вещи очень сильно преувеличена. Многие люди думают, например, что можно «схватить дозу» от деталей разобранного рентгеновского аппарата, от рентгеновских снимков и даже от врача-рентгенолога. А сколько шума поднимается, когда начинают говорить о гамма-облучении продуктов питания для их стерилизации! Мол, нам же придется есть облученную, а значит, радиоактивную пищу. Ходят и вовсе нелепые слухи о том, что в пище, разогретой в микроволновке, «остаются микроволны», о том, что под действием бактерицидных ламп становится радиоактивным воздух в комнате, где они горели.

В этой статье я расскажу, как все есть на самом деле.

На днях фильму «Матрица» исполнилось 20 лет. Офигеть, не правда ли?

По этому случаю WIRED сделал лонгрид на основе книги о сестрах (тогда еще братьях) Вачовски, из которого можно узнать много нового о карьере режиссеров-сценаристов до и во время создания культового фильма.

«Столкновение с землёй в управляемом полёте» (Controlled Flight into Terrain) — это авиационный термин, обозначающий аварию нормально функционирующего самолёта из-за того, что пилоты были чем-то отвлечены или дезориентированы. Настоящий кошмар. По моим оценкам, ещё хуже столкновение с землёй в автоматизированном полёте, когда система управления самолётом заставляет его совершать пикирование в землю, несмотря на отчаянные попытки экипажа спасти ситуацию. Такова предполагаемая причина двух недавних аварий новых самолётов Boeing 737 MAX 8. Я попытался разобраться, как могли произойти эти инциденты.

Примечание: изучение катастроф MAX 8 находится на раннем этапе, поэтому многое из статьи основано на данных из непрямых источников, другими словами, на утечках и слухах, а также на рассуждениях тех людей, которые знают или не знают, о чём говорят. Так что учитывайте это, если решите продолжить чтение.

Аварии

Ранним утром 29 октября 2018 года рейс 610 авиакомпании Lion Air вылетел из Джакарты (Индонезия) с 189 людьми на борту. Это был новый, эксплуатировавшийся всего четыре месяца 737 MAX 8 — последняя модель линейки самолётов Boeing, созданной ещё в 1960-х. Взлёт и подъём до высоты примерно 1 600 футов (480 метров) был нормальным, после чего пилоты убрали закрылки (элементы крыла, повышающие подъёмную силу при малых скоростях). В этот момент воздушное судно неожиданно снизилось до 900 футов (270 метров). В радиопереговорах с авиадиспетчерами пилоты сообщали о «проблеме с системой управления» и спрашивали данные о своей высоте и скорости, отображаемых на экранах радаров диспетчеров.

Так получилось, что я провожу довольно много собеседований на должность веб-программиста. Один из обязательных вопросов, который я задаю — это чем отличается INNER JOIN от LEFT JOIN.

Чаще всего ответ примерно такой: "inner join — это как бы пересечение множеств, т.е. остается только то, что есть в обеих таблицах, а left join — это когда левая таблица остается без изменений, а от правой добавляется пересечение множеств. Для всех остальных строк добавляется null". Еще, бывает, рисуют пересекающиеся круги.

Я так устал от этих ответов с пересечениями множеств и кругов, что даже перестал поправлять людей.

Дело в том, что этот ответ в общем случае неверен. Ну или, как минимум, не точен.

Приветствую, дорогой читатель!

Многие из Вас встречались с капчей — автоматическим тестом Тьюринга. Она позволяет отделить реальных людей от различных ботов. В последнее время очень популярной стала reCAPTCHA от Google Inc. На ней Вы должны выбрать изображения, содержащие некие объекты, к примеру, автомобили. Относительно недавно появился сайт, который делает ровно наоборот: отделяет ботов от людей.

Я уже перестал вздрагивать и удивляться, когда звонит телефон и в трубке раздается жесткий уверенный голос: «Вас беспокоит капитан такой-то (майор такой-то), вы можете ответить на пару вопросов?» Почему бы не поговорить с родной полицией…

Вопросы всегда одни и те же. «У нас есть видео с подозреваемым, пожалуйста, помогите восстановить лицо»… «Помогите увеличить номер с видеорегистратора»… «Здесь не видно рук человека, пожалуйста, помогите увеличить»… И так далее в том же духе.

Чтобы было понятно о чем речь — вот реальный пример присланного сильно сжатого видео, где просят восстановить размытое лицо (размер которого эквивалентен примерно 8 пикселям):


И ладно бы только русские дяди Степы беспокоили, пишут и западные Пинкертоны.

Недостаточно писать код хорошо читаемым: он также должен быстро выполняться.

Существует три базовых правила для написания такого T-SQL кода, который будет работать хорошо. Они кумулятивные – выполнение всех этих правил окажет положительное влияние на код. Пропуск или изменение любого из них – скорее всего приведет к отрицательному влиянию на производительность вашего кода.

• Пишите, исходя из структуры хранения данных: если вы храните данные типа datetime, используйте именно datetime, а не varchar или что-нибудь еще.
• Пишите, исходя из наличия индексов: если на таблице построены индексы, и они должны там быть, пишите код так, чтобы он мог использовать все преимущества, предоставляемые этими индексами. Убедитесь, что кластерный индекс, а для каждой таблицы он может быть только один, используется наиболее эффективным образом.
• Пишите так, чтобы помочь оптимизатору запросов: оптимизатор запросов – восхитительная часть СУБД. К сожалению, вы можете сильно затруднить ему работу, написав запрос, который ему «тяжело» будет разбирать, например, содержащий вложенные представления – когда одно представление получает данные из другого, а то из третьего – и так далее. Потратьте свое время для того, чтобы понять как работает оптимизатор и писать запросы таким образом, чтобы он мог вам помочь, а не навредить.

Существует несколько типичных ошибок, которые люди допускают в своем коде на T-SQL – не совершайте их.

Всем привет! На связи команда по улучшению продуктивности в .NET (aka. Roslyn). Мы много внимания уделяем улучшению вашего опыта .NET-кодинга. Ведь иногда небольшие дополнения и исправления действительно могут улучшить рабочий процесс. Возможно вы уже видели некоторые улучшения в превью-версиях VS2019. Но мы все равно хотим рассказать о некоторых из них, которые должны помочь вам работать продуктивнее.

Осторожно, много гифок.