В начале мая я решил получить сертификат TensorFlow-разработчика. Для этого я разработал программу обучения для совершенствования своих навыков и выполнил задания сертификационного экзамена пару дней назад (3 июня). Оказалось, что я сдал экзамен успешно.

Позвольте мне рассказать вам как я это сделал, и как вам сделать то же самое.

Погодите. Что вообще такое TensorFlow?

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

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

Обычно вы пишете код с использованием TensorFlow на очень понятном Python (именно это требуется для экзамена) или JavaScript (tensorflow.js), и он запускает ряд базовых функций, написанных на C. Эти функции выполняют описанные вами ранее команды (производят множество численных вычислений).

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

Такой измеритель в квартирах большая редкость прежде всего из-за высокой цены. Свой первый измеритель AZ Instruments 7798 CO2 datalogger я покупал за $139 и это была самая дешёвая модель на рынке.

Сейчас готовый измеритель CO2 стоит около 4000 рублей, а самодельный обойдётся вдвое дешевле.

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

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

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

Мы будем под кэшированием понимать сохранение результатов вычислений в ответ на некоторые запросы. То есть, повторный результат запроса не всегда вычисляется заново, но иногда берется из таблицы, называемой кэшем. Сложно переоценить роль кеширования в современных системах. При этом часто возникает проблема, связанная с недостатком памяти. Действительно, что делать, если запросов много, а памяти хватает лишь для хранения ограниченного числа результатов? В этом случае, как правило, кеш стрится следующим образом. Фиксируется размер кэша, пусть будет N, и сохраняются результаты только для N самых «популярных» запросов.

То есть сохраняются результаты вычислений, которые скорее всего запросят заново.
Как определять эти «популярные» запросы? Наиболее известным способом является LRU, о котором я и расскажу в этой статье.

1. Введение

Этот текст — небольшое обобщение моего опыта подачи заявок на Computer Science PhD с уклоном в machine learning в Северной Америке. Я постарался собрать в этом гайде свои просчеты (учиться лучше на чужих ошибках) и более-менее универсальные вещи, полезные всем. Но все равно нужно понимать, что это довольно индивидуальный опыт, поэтому ваша личная стратегия может отличаться. Например, в случае выбора вузов/научных руководителей или в написании statement of purpose. Ну или вы находитесь в других стартовых условиях по сравнению со мной (оценки, статьи, рекомендации).

Имейте в виду, что основная часть гайда писалась до получения результатов, потому что мне хотелось избежать «ошибки выживших» (survivorship bias) и проанализировать свой опыт безотносительно того, поступил я или нет. В конце руководства есть мои результаты: я поступил в 2 из 11 вузов, в которые подавался. На мой взгляд, все равно стоит избегать ошибок, которые я здесь буду описывать. Ну и нужно понимать, что в процессе подачи на ML PhD очень много шума, поэтому можно сделать все хорошо и пролететь и наверное даже наоборот.

Еще один доклад с Pixonic DevGAMM Talks — на этот раз от наших коллег из PanzerDog. Lead Software Engineer компании Павел Платто разобрал мета-сервер игры с сервисно-ориентированной архитектурой, рассказал, какие решения и технологии были выбраны, что и как у них масштабируется, и с какими трудностями пришлось столкнуться. Текст доклада, слайды и ссылки на другие выступления с митапа, как всегда, под катом.

От переводчика: Хоть посыл статьи Najaf Ali, переведённой ниже, и носит слегка рекламный оттенок («оставьте криптографию нам, экспертам»), но описанные в ней примеры показались мне довольно интересными и заслуживающими внимания.
Кроме того, никогда не будет лишним повторить прописную истину: не придумывайте свою крипто-защиту. И эта статья отлично иллюстрирует почему.

0. Вступление

Цель данной статьи собрать в небольшую кучку основную информацию, минимально достаточную для того, чтобы начать работать с докер на ежедневной основе и удалить с рабочей машины локально установленные apache, mysql, virtualenv, python3, mongodb, memchaced, redis, php5, php7 и весь остальной зоопарк, который мы используем при разработке, и который зачастую еще и конфликтует между собой от версии к версии.

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

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

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

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

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

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

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



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

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

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

И первым в списке станет популярный Народный мониторинг.

1. Научитесь гуглить
Быть программистом, — значит научиться искать ответы на свои вопросы. Научившись эффективно «гуглить», вы сэкономите много времени, затрачиваемого на разработку.

2. Не обещайте много, но делайте больше, чем обещали
Лучше сообщать вашей команде, что выполнение задачи займет три недели, но выполнять её за две, чем наоборот. Следуя этому принципу, вы выстроите доверительные отношения.

Необходимое вступление

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

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

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

Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.

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

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

Сегодня хотел бы довести крайне интересный, но часто покрытый тайнами для обычных смертных программистов раздел базы данных (БД) — уровни изолированности транзакций. Как показывает практика, многие люди, связанные с IT, в частности с работой с БД, слабо понимают зачем нужны эти уровни и как их можно использовать себе во благо.

Немного теории

Сами транзакции особых объяснений не требуют, транзакция — это N (N≥1) запросов к БД, которые выполнятся успешно все вместе или не выполнятся вовсе. Изолированность же транзакции показывает то, насколько сильно влияют друг на друга параллельно выполняющиеся транзакции.
Выбирая уровень транзакции, мы пытаемся прийти к консенсусу в выборе между высокой согласованностью данных между транзакциями и скоростью выполнения этих самых транзакций.
Стоит отметить, что самую высокую скорость выполнения и самую низкую согласованность имеет уровень read uncommitted. Самую низкую скорость выполнения и самую высокую согласованность — serializable.

Ранее мы рассказали, какие исследования стоят за популярными советами о том, как «научиться учиться». Затем обсудили метакогнитивные процессы и полезность «каракулей на полях».

В третьей части — рассказали, как тренировать память «по науке». Кстати, про память — говорили отдельно тут и тут, еще — разбирались с тем, как «учиться по карточкам».

Сегодня — обсудим концентрацию, «многозадачность» и прокачку внимания.

Чем Java отличается от других популярных языков? Почему именно Java может быть первым языком для изучения? Давайте составим план, который поможет выучить Java как с нуля, так и с применением навыков программирования на других языках. Перечислим отличия между созданием продакшен-кода на Java и разработкой на других языках. Михаил Затепякин прочитал этот доклад на встрече для будущих участников стажировки Яндекса и других начинающих разработчиков — Java Junior meetup.


— Всем привет, меня зовут Миша. Я разработчик из Яндекс.Маркета, и сегодня я расскажу вам, зачем учить Java и как делать это эффективно. Вы можете задать резонный вопрос: почему это буду рассказывать я, а не какой-нибудь сильный разработчик с кучей лет стажа? Дело в том, что я сам изучал Java недавно, года полтора назад, поэтому еще помню, как это примерно было и какие есть подводные камни.

Тренируйте мозг, изменяйте нейронные связи

Наш мозг на удивление динамичен и постоянно меняется. Он умеет приспосабливаться, лечиться, обновляться и изменять нейронные связи.

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

Эксперименты по нейропластичности (это способность мозга изменяться в ответ на получаемый опыт) показали, что мозг умеет меняться — изменяя свою структуру, биохимию, увеличиваясь и уменьшаясь в размерах.

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

Переведено в Alconost

^{Приобрести VDS со скидкой 30%, да ещё и до повышения цен. Шутка :) Но в каждой шутке есть доля правды.}

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

После Cybertruck мы решили не включать дизайн в список перспективных направлений для айтишников в 2020 году. Что есть внешность вещей? Ничто рядом с их сутью