Data Science требует использования статистических методов и алгоритмов машинного обучения для работы с большим объёмом данных, и для того чтобы делать это эффективно, вам потребуется много практики. Отличная возможность попрактиковаться — соревнования по Data Science. Они служат платформой для изучения лучших практик, получения отзывов и повышения квалификации. Это также отличный способ расширить возможности творить и границы в области науки о данных. Я делал подобный список и в прошлом году, поэтому подумал, что это будет хорошее время, чтобы обновить его на 2021 год.

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

Пишем свой язык программирования (на Swift)

Для того, чтобы написать свой язык программирования, необязательно иметь степень в Computer Science, достаточно понимать 3 базовых шага.

Язык: Mu(μ)

Mu — это минимальный язык, который содержит постфиксный оператор, бинарную операцию и «одноциферные» числа.

Пример: (s 2 4) or (s (s 4 5) 4) or (s (s 4 5) (s 3 2))…

Мы живем в свободной стране. Любой может приобрести «игрушку», за которую в США светит штраф $112,000 (джаммеры так же признаны вне закона в Англии, Странах Евросоюза, Австралии, Канаде, Индии, Сингапуре и пр)

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

Обзор 5-канальной глушилки ГРН40-А5

В 2012 году обсуждался вопрос широкого использования GSM-глушилок в общественных местах.
В 2014 российские разработчики представили свой аппарат для ЕГЭ.
В 2014 журнал «Хакер» признал глушилки (jammer) полезным гаджетом.
В феврале 2015 года африканский злоумышленник протащил глушилку в парламент.

Что интересно, началась веселуха и на глушилки появляются антиглушилки (и обнаружители глушилок), а на них в свою очередь появляются глушилки антиглушилок и тд.

Содержание

1. Введение в Computer Science
2. Структуры данных и Алгоритмы
3. Системное программирование
4. Распределенные системы
5. Базы данных
6. Объектно-ориентированный дизайн и разработка софта
7. Искусственный интеллект
8. Машинное обучение
9. Веб-разработка и интернет-технологии
10. Concurrency
11. Компьютерные сети
12. Разработка мобильных приложений
13. Математика для программистов
14. Теория информатики и языки программирования
15. Архитектура компьютера
16. Безопасность
17. Компьютерная графика
18. Работа с изображениями и компьютерное зрение
19. Интерфейс Человек-Компьютер
20. Вычислительная биология
21. Прочее

Какая была первая публикация Кнута, каким послушным ботаном он был в школе, и почему любил музыку больше, чем математику.



Я окончил Лютеранскую Среднюю Школу в Милоуки (Milwaukee Lutheran High School,) в 1956. У нас не было преподавателей «мирового масштаба», но все они были заинтересованы в нашем образовании.

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

Alyson La, Data science в GitHub: В октябре этого года я отпраздновала свой пятилетний юбилей работы в GitHub. 5 лет назад я была бухгалтером, который ничего не знал о программировании, не говоря уже об использовании Git и GitHub.

Теперь я энтузиаст Data Scientist, который знает некоторые вещи о написании кода с помощью Git & GitHub. Частично благодаря изучению этих технологий я сделала этот карьерный переход.

Но даже работая в GitHub, изучать Git и GitHub было сложно! Поэтому я хочу поделиться 5-ью советами по использованию GitHub с другими людьми, новичками программирования.

Совет № 1: Измените редактор по умолчанию

Для многих людей текстовый редактор при использовании Git через терминал — VIM. VIM может быть ужасным, страшным для нового или казуального хакера. Или даже для ветеранов-хакеров как @haacked.


Если вы когда-нибудь столкнетесь с конфликтами слияния (а вы их встретите, см. совет №4), вы попадете в VIM, чтобы исправить конфликт, и вам нужно будет знать конкретные команды VIM для редактирования документа иначе вам захочется плакать. Больше года у меня была заметка на мониторе для напоминания основных команд VIM, таких как i (для редактирования) и: wq (для сохранения и выхода). Чтобы избежать боли, вы можете просто выбрать другой текстовый редактор.

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

Ключевой частью инженерии является любовь к тому, чтобы делать вещи, особенно к тому, чтобы делать их сразу же и делать их хорошо. Большая часть инженерии возникла из “tinkering” (aka “hacking”), добавив к этому желания «принципиального проектирования и создания», «целостности» и т. д. Все великие инженеры, которых я знаю лично, имеют глубокие моральные убеждения касательно того, что они делают, и почему это «должно быть сделано как можно лучше». Часть наложения темперамента на науку это своего рода «лабораторная крыса», которая наиболее счастлива, когда она в курсе эксперимента или создания нового экспериментального аппарата.

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

Вы можете удивиться: зачем же разработчику ПО думать о механизме кэширования в CPU? Отвечу. С одной стороны, многие понятия из концепции когерентности кэша непосредственно применимы в распределённых системах и на уровнях изоляции СУБД. Например, представление реализации когерентности в аппаратных кэшах помогает лучше понять разницу в моделях согласованности (консистентности) — отличие строгой согласованности (strong consistency) от согласованности в конечном счёте (eventual consistency). У вас могут появиться новые идеи, как лучше обеспечить согласованность в распределённых системах, используя исследования и принципы из аппаратного обеспечения.

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

Виктор Тарнавский показывает, что оно работает. Перед вами расшифровка доклада Highload++ 2016.

Здравствуйте. Меня зовут Виктор Тарнавский. Я работаю в «Яндексе». Расскажу про очень быструю, очень отказоустойчивую и супермасштабируемую базу данных ClickHouse для аналитических задач, которую мы разработали.

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

У вас часто бывает, что вы забегаете на встречу (стендап, ретро, еженедельную встречу с коллегами, f2f с начальником — нужное подчеркнуть), а ваши мысли остаются где-то за пределами комнаты?

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

Около трети наших сотрудников — друзья или родственники тех, кто уже работал в компании на момент их трудоустройства. Более того, именно они привели их в Туту.ру. Только вот о «кумовстве» никакой речи здесь не идёт — просто наши сотрудники всегда с радостью рекомендуют Туту.ру своим друзьям (и рассказывают о друзьях HR-отделу). Расскажу, как добиться тех же результатов и почему это хорошо для любой компании.

Читаешь текст. Быстро, не проверяя, не проговаривая, одними глазами. И останавливаешься, потому что что-то глаз зацепил некрасивое, неправильное, режущее.

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

Я один такой? Почему так?

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

Программисты знакомые с ctypes врядли найдут тут что-то интересное, новичков же прошу под кат.

Прошел первый раунд отбора участников в школу программистов HeadHunter, анонс на хабре
Где после заполнения анкеты предлагалось решить 5 задачек

Несколько недель назад в рамках учебного курса в университете мне посчастливилось встретиться с Руководителем отдела по подбору персонала компании «Яндекс» Евгенией Шкуратовой и задать вопросы о состоянии IT-рынка и возможности работы в этой сфере. Темы, поднятые в разговоре, оказались настолько животрепещущими, что дискуссия затянулась на 3 часа. В этой статье я постараюсь воссоздать мазок за мазком образ современной сфере IT (естественно через призму восприятия компании «Яндекс»).

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

Подобные средства есть для всех распространенных настольных ОС, включая Linux и BSD, и многие из них совершенно бесплатны, так что вряд ли имеет смысл ограничивать себя в Блокнотом Windows, nano или cat.

Однако, в среде поклонников Unix гуляет в разнообразных вариациях мем о том, что «Unix — это IDE», в том смысле, что средства, которыми разработчики располагают в терминале, легко реализуют основные возможности современных IDE. Вы можете соглашаться или отказываться признать Unix «IDE» в том самом смысле, что Eclipse или Microsoft Visual Studio. Так или иначе, вас скорее всего удивит, насколько законченную среду разработки может являть собой скромный Bash.

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

Под Unix существует множество компиляторов и интерпретаторов, но здесь мы будем обсуждать лишь gcc как средство компиляции C-кода, и коротко коснемся использования perl в качестве примера интерпретатора.

GCC

GCC — это набор компиляторов, обладающий очень почтенным возрастом и распространяемый под лицензией GPL. Он известен как инструмент работы с программами на C и C++. Свободная лицензия и повсеместная распространенность на Unix-подобных системах стали залогом его неизменной популярности, хотя есть и более современные альтернативы, использующие инфраструктуру LLVM, такие как Clang.

Текстовый редактор — это основной инструмент для любого программиста, вот почему вопрос его выбора становится причиной яростных дебатов. Unix традиционно тесно связан с двумя своими многолетними фаворитами, Emacs и Vi, и их современными версиями GNU Emacs и Vim. Эти редакторы имеют очень разный подход к редактированию текста, но при этом сравнимы по мощи.

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

(оригинал — Jasper St. Pierre, разработчик GNOME Shell, взято отсюда)

Это обзорная статья о составных частях графического стека Linux и том, как они уживаются вместе. Изначально я написал её для себя после разговоров об этом стеке с Оуэном Тейлором, Рэем Строудом и Эдэмом Джексоном (Owen Taylor — мэйнтейнер Gnome Shell; Ray Strode — мэйнтейнер большого количества десктопных пакетов сообщества RedHat; Adam Jackson — разработчик графического стека Gnome Shell и интеграции с XOrg; прим. переводчика). 

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