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

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

Итак, сайты для обучения программированию онлайн, ТОП 100:

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



В повседневной работе в Linux / Unix мы используем множество инструментов командной строки — например, du для мониторинга использования диска и системных ресурсов. Некоторые из этих инструментов существуют уже давно. Например, top появился в 1984 году, а первый релиз du датируется 1971 годом.

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

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

CI (Continuous Integration) — в дословном переводе «непрерывная интеграция». Имеется в виду интеграция отдельных кусочков кода приложения между собой. Чем чаще мы собираем код воедино и проверяем:

• Собирается ли он?
• Проходят ли автотесты?

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

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

Ни для кого не секрет то, что команда разработчиков Flutter стремится к тому, чтобы этот фреймворк позволял бы, пользуясь единой кодовой базой, создавать приложения для широкого разнообразия платформ. Сюда входят iOS, Android, Windows, Linux, macOS и веб. При этом такие приложения должны компилироваться в формат, специфичный для каждой из платформ, а их внешний вид не должен уступать внешнему виду хорошо сделанных игр. В Google фреймворк Flutter применяется во многих проектах: от Assistant до Stadia, от Cloud Search до Blogger. Flutter используются и другими компаниями — от ByteDance до Grab, от Nubank до MGM Resorts. Всем им приносит пользу та гибкость и продуктивность разработки, которую даёт Flutter.

Многие из вас заинтересованы в развитии возможностей Flutter, касающихся настольных платформ, куда входят Windows, macOS, Linux. В опросах и на GitHub тема разработки настольных приложений относится к одной из самых заметных новых возможностей Flutter. В ближайшее время мы собираемся больше рассказать о том, чем мы занимаемся. Полагаем, стоит начать с обзора того, что сделано различными командами, отвечающими за возможности Flutter. Хотя поддержка настольных приложений пока находится на стадии ознакомительной технической версии, над соответствующими возможностями ведётся серьёзная работа.

Как не убить критикой, но и не скатиться в поверхностное ревью? Жирный PR против кучи мержей — что где выгоднее в зависимости от типа и размера проекта? А вот оно вообще правда нужно? Может, ну его — или автоматизируем/заменим статическим анализом?

Тема благодатная — и мы решили посвятить ей совместный стрим с подкастом SDCast.


1 июля в 17 часов по Москве/Киеву/Минску. В эфир придут хорошие люди (о них под катом) — а еще у нас будут свои голосования ;)

Aqua-Fi — это новая технология для скоростного беспроводного интернета под водой. Обычный Wi-Fi в этих условиях бессилен.

Подводные телекоммуникации всегда были проблемой. Радиосигналы, повсеместно распространенный беспроводной стандарт, в этом случае непригодны для использования, так как их полностью поглощает вода. Акустические передатчики (например, гидролокатор) работают под водой лучше, но они страдают от очень низкой скорости передачи данных. Неплохо было бы использовать Wi-Fi под водой, правда?

Мы в Badoo постоянно мониторим свежие технологии и оцениваем, стоит ли использовать их в нашей системе. Одним из таких исследований и хотим поделиться с сообществом. Оно посвящено Loki — системе агрегирования логов.

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

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

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

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

amazon litres

В прошлом году я участвовал в соревнованиях JS13K 2019, на которых людям предлагается разрабатывать игры в менее чем 13 КБ кода на JavaScript. Я участвовал с клоном Doom, который назвал… «Ещё один клон Doom» (Yet Another Doom Clone).


Поиграть в него можно здесь. Исходный код выложен сюда.

Зачем создавать клон Doom?

Зачем писать FPS на JavaScript всего в 13 КБ (с учётом сжатия)? По нескольким причинам. Но лучше всего на этот вопрос отвечает раздел FAQ соревнований JS13K «Можно ли использовать WebGL?»:

«Да, но может быть сложно уместить его в 13 килобайта, если вы планируете писать FPS».

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

Именно поэтому я выбрал FPS. Остаётся вопрос: «Почему Doom?» На него ответить проще: если вы хотите написать FPS, и чтобы он при этом был небольшим, то Doom — практически самый минималистичный вариант.

Всем привет!

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

О том, как мы начинали, я писал в статье.

С тех пор многое изменилось — мы стали поддерживать еще больше чипсетов, например, таких как mstar и fullhan, познакомились и подружились с большим количеством как иностранных, так и отечественных производителей IP камер.

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


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

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

Но, однако, сегодня, читая новости в фейсбуке и попивая утренний кофе — чуть не разлил его, прочитав новость о том, что дочка Роснано, компания ЭЛВИС-НеоТек, совместно с Ростехом поставит десятки тысяч камер в школы.

Под катом — детали того, как мы их тестили.

Как может машина понимать смысл слов и понятий, и вообще, что значит — понимать? Понимаете ли вы, например, что такое спаржа? Если вы скажете мне, что спаржа — это (1) травянистое растение, (2) съедобный овощ, и (3) сельскохозяйственная культура, то, наверное, я останусь убеждён, что вы действительно знакомы со спаржей. Лингвисты называют такие более общие понятия гиперонимами, и они довольно полезны для ИИ. Например, зная, что я не люблю овощи, робот-официант не стал бы предлагать мне блюда из спаржи. Но чтобы использовать подобные знания, надо сначала откуда-то их добыть.

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

Всем привет! Весенний семестр для некоторых студентов 3-го курса ФУПМ МФТИ ознаменовался сдачей проектов по курсу «Методы оптимизации». Каждый должен был выделить интересную для себя тему (или придумать свою) и воплотить её в жизнь в виде кода, научной статьи, численного эксперимента или даже бота в Telegram.

Жёстких ограничений на выбор темы не было, поэтому можно было дать разгуляться фантазии. You Only Live Once! — воскликнул я, и решил использовать эту возможность, чтобы привнести немного огня в бессмертную классику.

Введение

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



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

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

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

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

«Опять те же грабли», — сказала мне жена, когда я в очередной раз задерживался с работы. «Проект интересный, надо доделать», «Сейчас поднажму, потом будет легче», — мой типичный набор ответов на переработки.

С удалённой работой перегрузить себя ещё проще — ходить никуда не надо, никто не зовёт попить кофе, а список вариантов отдохнуть «снаружи» сократился.

В онлайне только и разговоров, как работать эффективно и сохранять баланс с отдыхом, но ведь гораздо проще включить YouTube, заесть чем-то сладеньким. Через час устать ещё больше: «Какого чёрта, я хотел посмотреть полезное видео, а смотрю как УАЗ наматывается на столб»?!

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

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

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

Статья о том как делать трекинг. Где он используется, какие есть разновидности. Как сделать стабильное решение.

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

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



Что это такое? В двух словах — «человек ищет подтверждение своей модели, а не её опровержение». Единственный шанс объяснить лучше, это примеры-примеры-примеры и опыт. Лишь так можно развить чувство что «что-то тут не так».

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

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

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

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


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

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

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