На написание данной статьи меня вдохновила статья об анализе Сишного printf. Однако, там был пропущен момент о том, какой путь проходят данные после того, как они попадают в терминальное устройство. В данной статье я хочу исправить этот недочет и проанализировать путь данных в терминале. Также мы разберемся, чем отличается Terminal от Shell, что такое Pseudoterminal, как работают эмуляторы терминалов и многое другое.

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

Как-то раз я взломал один из серверов telegram. Не то чтобы это было нечто интересное, да и сами уязвимости стандартные. Удивление скорее вызывает факт того, как телеграм относится к безопасности и почему на протяжении многих лет уязвимостями так никто и не воспользовался. Но, не ошибается тот, кто ничего не делает!

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

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

Что же делать? Как работать с Игнатом? Добро пожаловать под кат!

Привет! Хочу рассказать про то, чем японское видение разных интерфейсов в реале отличается от нашего. Как всегда, эти мелочи могут сказать о культурной среде очень многое.

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



А вот термометр. Они здесь часто круглые, и при этом есть цветовая индикация.



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

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

Продолжение.
Предыдущие части: 1-3, 4-6, 7-9

10. Нормализация баз данных

Указания для правильного проектирования реляционных баз данных изложены в реляционной модели данных. Они собраны в 5 групп, которые называются нормальными формами. Первая нормальная форма представляет самый низкий уровень нормализации баз данных. Пятый уровень представляет высший уровень нормализации.

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

В данной теме я затрону 6 нормальных форм и методы приведения таблиц в эти формы.

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

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

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



Откуда он взялся? Из простой мысли, что иногда люди выходят из офиса поесть что-то снаружи. Ближайший магазин у нас в 10 минутах от офиса (с учётом спуска-подъёма). Гораздо дешевле и практичнее принести сотрудникам бесплатную еду, чем тратить их время на её поиски, пускай и не за счёт компании. Сначала это были только здоровые закуски, но потом по мере роста офиса стали появляться сосиски, а для тех, кто иногда остаётся ждать ночи перед релизом, — пицца. При этом горячая еда тут не хранится постоянно, а приезжает отдельно.

Давайте проанализируем, как такое решение вообще могло быть принято.

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

Скоро наступит десятый год, как я профессионально занимаюсь программированием. Десять лет! И кроме формальной работы, почти две трети своей жизни я что-то создавала в интернете. С трудом вспоминаю годы, когда я не знала HTML: даже странно, если подумать об этом. Некоторые дети учатся музыке или балету, а я вместо этого создавала волшебные миры, кодируя в своей детской.

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

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


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

Ведущий разработчик — не зря «ведущий». Эту фраза была услышана на одной из конференций по IT-менеджменту и вызвала вопрос, а почему собственно «не зря»? Именно этот вопрос и подтолкнул меня написать эту статью.



Оценивая свой опыт, могу сказать, что основные характеристики ведущего разработчика можно свести к 3 пунктам:

• Думает не только о своей грядке, но и обо всем огороде (это ключевое качество). Готов выстраивать стандарты и следить за их исполнением.
• Отлично знает свой язык и фреймворк, превосходно разбирается в архитектуре, имеет солидный опыт работы за плечами. «Солидность» не обязательно означает время проведенное за клавиатурой, важно количество и качество написанных проектов.
• Хочет и может аргументированно доносить свое мнение, отстаивать его и искать компромисс при необходимости.

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

Одной из сильнейших его сторон является целостная картина мира, в которой совершенно точно определено, что такое хорошо и что такое плохо. Это позволяет быстро принимать решения и без колебаний воплощать их в жизнь. Эта уверенность заразительна и позволяет завоевать авторитет в глазах менеджеров, у которых уже не все так просто и понятно. Ведь кроме технических «лучше», «надежнее» и «быстрее», на уровне менеджмента появляются всякие «заказчик не захочет», «инвестор не оценит» и всевозможные «Вася обидится». Когда менеджер слышит «нет, тут нужно делать только так, потому что 1, 2 и 3» — он вздыхает с облегчением. Выбор становится очевиден и ответственность падает с его плеч.

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

Ошибка номер 1. Оверменеджмент

Прим. переводчика:

Недавно создатель NodeJS Райн Дал открывал конференцию HolyJS в Питере. И я вспомнил, что у меня есть неопубликованный перевод с его блога и решил его опубликовать. Местами перевод довольно откровенный. Надеюсь, вам будет интересно. Дата выхода статьи — Октябрь 2011. Дата выхода NodeJS — 27 Мая 2009.

Ранее каждый раз, когда я видел сообщения о том, что у человека украли телефон, то всегда задавался вопросом: а зачем? Ну, серьезно, зачем воруют смартфоны если:

• его можно отследить по IMEI, а смена IMEI явно не бесплатна;
• на телефоне могут быть установлены блокировки, снять которые так же не бесплатно;
• есть приложения с режимом «Антивор», которые передают фото, видео и аудио;
• даже встроенные возможности Android (и, полагаю, iOS) имеют функцию геолокации пропавшего устройства;
• устройство может иметь особые приметы, которые довольно сложно устранить «бесплатно»;
• наверняка где-то рядом есть камеры видеонаблюдения, свидетели и т.п.;
• при продаже краденного за него сложно будет выручить большую сумму денег.

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

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

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

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

Мы верим, что в будущем люди будут управлять своим домом с помощью голоса, а не кнопок. Поэтому сегодня Яндекс представляет платформу умного дома, которая позволит зажечь свет, убавить температуру на кондиционере, переключить телевизор на другой канал или даже сварить кофе — с помощью Алисы.

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

На Хабре тема удалёнки поднимается постоянно. Был откровенный пост, который отозвался до самых глубин сердца. Сегодня случился рекламный пост, где понятие удалёнщика как-то путается с понятием фрилансера. А сейчас будет эмоциональный пост — от простой девчонки, которая вот уже 4 года работает удалённо менеджером в сфере IT. Побуду разрушителем мифов, капитаном очевидностью и чуваком с долларами, но о последнем в другой раз.

Как вариант — изолировать занудных трудоголиков

Не так давно я работал контрактником, перескакивая с одного проекта на другой. С некоторыми краткосрочными проектами справлялся за неделю. Другие длились пару месяцев. Они приносили достаточно денег, чтобы взять отпуск. Но я предпочитал короткие, потому что там можно было установить бóльшую часовую ставку. Я не только сам себе хозяин, но и не приходилось слишком много работать, чтобы зарабатывать на жизнь. Даже мои самые высокие ставки были вполне разумными, и я всегда обеспечивал высокое качество обслуживания. Так было до тех пор, пока мне не предложили контракт в большой компании.

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

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

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

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