Рубрика «ruvds_перевод» - 11

Загадочное дело о пропавшей точке - 1


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

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

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

Почему для меня так важен алгоритм CORDIC - 1


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

Перейду сразу к делу и скажу, почему я так сильно люблю этот алгоритм, а затем займёмся изучением принципов его работы. По сути, фактические операции CORDIC весьма просты — как я уже сказал, это сдвиги и сложение — но выполняет он их путём комбинирования векторной арифметики, тригонометрии, доказательств сходимости и продуманных техник компьютерных наук. Лично я считаю, что именно это имеют ввиду, описывая его природу, как «элегантную».Читать полностью »

Собираем балансирующий куб - 1


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

Первоначальная идея этого устройства взята у исследователей Швейцарской высшей технической школы Цюриха, продемонстрировавших в этом видео свой Cubli. За последующие годы дизайн в определённых аспектах был усовершенствован. В частности, Bobrow et al (Университет Сан-Паулу) предложили улучшенную концепцию управления, уменьшающую количество IMU (блоков инерциальных датчиков) с шести до всего одного.

Я решил собрать такое устройство. Хотя идея и не нова, все предыдущие работы по этой теме в основном имели закрытые исходники. Я планирую изменить ситуацию. Это значит, что мне придётся выполнить реверс-инжиниринг и начертить всё с нуля. Результат моей работы, полностью опенсорсный (GitHub), показан в видео.
Читать полностью »

Сложности перевода: баг, который говорил по-русски и ломал моё приложение - 1


Шпион всматривается в экраны

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

Со всеми этими задачами я справился за день и, проведя несколько тестов, выпустил новую версию...Читать полностью »

Как случайно баллотироваться на пост президента Исландии? - 1


Чтобы баллотироваться на должность президента Исландии, нужно быть гражданином этой страны в возрасте от 35 лет и собрать от 1 500 до 3 000 подписей избирателей.

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

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

Многие из этих людей действительно конкурируют за пост президента (да, среди них моя тётя Хельга), некоторые явно подали заявку в качестве шутки (нет, не упомянутый выше комик), и не менее 11 из них зарегистрировались случайно, понятия не имея о том, что начали сбор подписей в поддержку своего выдвижения. Читать полностью »

Забытая война с пейджерами - 1


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

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

В течение 1980-х эти устройства активно набирали популярность среди подростков, а также… драг-дилеров. В те годы США переживали общественную панику, связанную с активным употреблением наркотиков молодёжью, и этот факт значительно её усилил, поскольку пейджеры начали считать одним из главных подспорьев наркобизнеса. Читать полностью »

Стресс и выгорание в мире разработки ПО - 1

Автор: Sow Ay

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

Если вспомнить конкретно 2017 год, то он стал для меня весьма неприятным. Я регулярно испытывал панические атаки, сидел на релаксантах и пытался писать код, находясь под серьёзным давлением дедлайнов и новых ответственностей. Тогда я как раз унаследовал от своего предшественника должность главы отдела информационных технологий. Теперь я отвечал за небольшую команду разработчиков. При этом наш стартап дал многим партнёрам множество обещаний. Моей же задачей была их реализация, и я мог их либо нарушить, либо выполнить. У меня получилось и то и другое.Читать полностью »

Не бойтесь бросать свои пет-проекты - 1

Веб-индустрия переполнена историями о пет-проектах, которые переросли в успешный бизнес. Вот и я нередко увлекаюсь какими-нибудь идеями после основной работы. И хотя это определённо заманчивая перспектива, работа над личным проектом не всегда столь лучезарна – порой они просто не выгорают. Если вы читаете эту статью, то есть вероятность, что вы недавно отказались (или подумываете отказаться) от своего пет-проекта. В таком положении находились многие из нас. Да что тут говорить, заброшенные личные проекты даже стали своего рода мемом в среде разработчиков.

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

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

И здесь я хочу рассказать о своём недавнем пет-проекте, который забросил в тот же день, в который запустил. Читать полностью »

Эффект Монреаля: почему языкам программирования нужен Царь стилей - 1


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

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

Какое подмножество C++ или Kotlin вы используете? Что вы предпочтёте: project.toml или requirements.txt? Теперь у вашего языка есть возможность поэтапной типизации с помощью аннотаций типов. Хотите ей воспользоваться? Как вы реализуете конкурентность: с помощью многопоточности, Tokio или std::async?

Чем более экспрессивный язык, тем сложнее всё становится. И здесь на сцену выходит Go. И речь не только о gofmt, но и о его стандартной библиотеке и согласованности. В Kotlin вам приходится гадать, что лучше использовать для ошибок: исключения или объекты Result? В случае же Go вам всё ясно – ищем err. Да, это многословно, но зато предсказуемо.

Экспрессивные языки прекрасны, но часто создают путаницу. Вы можете использовать богатый и комплексный язык, поддерживающий миллион способов реализации одного и того же. Именно это я хочу вам показать. Как же сохранить всю эту мощь, но уменьшить беспорядок? Как избежать возникновения 500 поддиалектов? Но прежде, чем переходить к решениям, обсудим Scala.Читать полностью »

Делаем код-ревью правильно - 1


В начале своей карьеры я как-то работал над одним заказом, создавая платформу сентимент-анализа для социальных сетей. В то время Twitter ещё был Twitter’ом. Наша команда состояла из семи человек, среди которых я был джуниором. Мы были молоды и полны энтузиазма. Наш девиз можно было описать как: «Мы гибкие, быстрые и всё ломаем!». Да, мы действительно гордились своей скоростью. Код-ревью? Я вас умоляю. Мы считали эту практику бюрократическим пережитком корпоративного мира.

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

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

Итак, в двух словах: если вы не проводите код-ревью, или делаете их «для галочки», то обрекаете себя на боль, пусть не сразу, но в конечном итоге однозначно. Это можно сравнить с возведением дома на фундаменте из песка. Какое-то время он, может, и простоит, но явно недолго. А в мире стартапов второго шанса у вас может уже не быть.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js