Android developer
Всем известный закон Мёрфи гласит: «Если что-то плохое может случиться, то оно обязательно произойдет». Согласитесь, не самая позитивная установка, особенно когда это касается работы. И тут мне стало любопытно, а есть ли такие законы, которые мне, как ИТ-специалисту, максимально помогут избежать «чего-то плохого». К своему удивлению, я их нашел, и даже не один. Потому делюсь с вами сегодня своими сакральными знаниями в блоге ЛАНИТ.
Здесь собраны лучшие и самые полезные репозитории Github, которые будут служить вам долгое время.
Это продолжение нашего рассказа о внедрении Kotlin Multiplatform Mobile в QIWI. Если хотите узнать больше про технику, посмотреть на код, переходите в первую часть. В этой статье будет больше контекста про то, как мы принимали решение, готовили прототип и внедряли технологию в команды. Наш опыт может помочь вам “продать” KMM в вашей компании и вашим стейкхолдерам. Я расскажу о плюсах и сложностях, с которыми мы столкнулись на нашем пути.
Немного истории
В QIWI мы часто пробуем что-то новое в наших процессах и в разработке. За последние 5 лет мы создали несколько приложений с нуля, используя разнообразные подходы. Например, мы впервые попробовали кросс-платформу, когда делали приложение QIWI Инвестор. Мы использовали инструмент J2ObjC, чтобы конвертировать общий модуль с кодом на Java на Objective-c для iOS. Это решение было смелым, но не самым надежным. По ходу использования было много проблем, самые большие — с конвертацией кода сторонних библиотек. В итоге проект закрылся, как и этот эксперимент. Кросс-платформенный подход оказался рабочим, но мы отложили его в сторону пока не появился более надежный инструмент.
В 2018 году мы перешли от платформенных команд к кросс-функциональным. Это стало самым большим изменением в процессе разработки c внедрения скрама. “Совместное владение кодом” стало нашей новой ценностью. Границы между платформами начали размываться, мы стали внимательнее изучать код на других платформах, вместе принимали решения и делились лучшими практиками.
В последнее время случилась (и продолжает случаться) тьма публикаций про кадровый голод в айти, про переоценённость синьоров, недооценённость всех остальных, про золотые горы, скандалы, интриги и конский перекос баланса фракции "программисты". Ну, короче, вы сами всё читали и вполне себе в теме. Так вот, в сим опусе хочется вспомнить, а ктож такой синьор и что ему крайне желательно знать, чтобы синдром самозванца не накрывал и чтобы окружающие уважали и на поклон за советом приходили.
Статья для тех, кто боится слова template в C++. Вводная информация с примерами и их подробным разбором.
Если открыть вакансии QA, можно увидеть огромный разброс открытых позиций — от младшего тестировщика до ведущего, а иной раз и до главного. Часто слышу вопрос, чем должен обладать тестировщик уровня сеньор по сравнению с джуном или мидлом. Сейчас попробую на него ответить.
За 9 лет работы в роли Head of QA, я для себя сформулировал набор качеств и модель поведения, которым должен соответствовать настоящий сеньор QA. Своими наблюдениями поделился под катом.
Меня всегда поражало, что основы всей нашей цивилизации были заложены людьми, жившими две с половиной тысячи лет назад и не имевшими почти никаких способов получения знаний о мире кроме собственного разума - только лишь с помощью него одного они по капле воды смогли догадаться о существовании океана.
В этом посте я хочу рассказать про трех великих философов античности, чьи идеи о природе сущего находят подтверждение в теориях квантовой механики и самых смелых гипотезах современной теоретической физики.
Как появился Пегас?
Величайшим из древнегреческих философов по праву считается ученик Сократа афинянин Платон. Именно благодаря его "Диалогам" до нас дошла большая часть сведений о греческой философской мысли.
Несмотря на то, что Платон изучал и даже преподавал математику, никаких особенных математических достижений он после себя не оставил. Но все же девизом основанной им Академии он избрал фразу "Не геометр да не войдет", тем самым подчеркнув важность математики для познания мира и формирования ума.
Основной идеей философии Платона была, извините за каламбур, сама "идея". Именно он ввел в оборот это слово, которое на древнегреческом звучало как "эйдос". Для объяснения своей теории Платон обычно использовал аллегорию, позже ставшую известной как миф о пещере. Я вкратце приведу здесь только самую ее суть.
Представьте себе абсолютно пустую белую комнату. В этой комнате нет дверей, на одной из стен почти под потолком располагается единственное окно. Под этим окном стоит кресло, к которому железными цепями крепко-накрепко привязан человек. Его голова и тело зафиксированы таким образом, что единственное, что он видит - противоположную от окна стену. Этот человек в раннем детстве был похищен учеными, подключен к системам жизнеобеспечения и привязан цепями к своему креслу, он вырос в этой комнате и никогда не видел мира за ее пределами. Время от времени ученые проносят за окном какие-то предметы: статуи, изображения животных, растений, зданий. Узник не видит самих предметов, а видит лишь только тени, отбрасываемые ими на противоположную от окна стену комнаты. Он различает в этих тенях схожие паттерны и дает им названия. Узник искренне считает, что те тени на стене, что он видит и которым дает имена - реальны.
Привет! Меня зовут Седов Фёдор, я ученик 11 класса и выпускник «IT Школы Samsung» 2020 года. Мне предложили рассказать о своём опыте разработки мобильного приложения, моего первого большого проекта - блокнота для музыкантов (и поэтов). С этим проектом я одержал победу в нескольких конкурсах, а сейчас мечтаю, что у приложения появится много пользователей, которым оно будет помогать каждый день.
Вы вряд ли найдете в интернете что-то про разработку ботов, кроме документаций к библиотекам, историй "как я создал такого-то бота" и туториалов вроде "как создать бота, который будет говорить hello world". При этом многие неочевидные моменты просто нигде не описаны.
Как вообще устроены боты? Как они взаимодействуют с пользователями? Что с их помощью можно реализовать, а что нельзя?
Подробный гайд о том, как работать с ботами — под катом.
Java и другие управляемые языки просты и удобны во многих случаях, но иногда их возможностей недостаточно — например, если нужна библиотека, написанная только на C или C++. Иногда хочется позвать пару методов из системного API, или попытаться улучшить производительность для модуля — и тогда прямой путь в нативный код.
Но тут возникают подводные камни: написать нативный метод и вызвать библиотеку может быть и легко, но JVM начинает крашиться в случайных местах, производительность падает, сборщик мусора перестает справляться с работой, а в репозитории царствуют бесконечные C-шные файлы с буквами JNI. Что же могло пойти не так?
Иван Углянский (dbg_nsk) из Huawei разбирается со всем по порядку: что необычного в интеропе между Java и нативным кодом, как оно работало раньше и что нужно делать для их нормальной совместной работы (и можно ли это вообще сделать). Иван рассказывает, как избежать просадок производительности, внезапных OOM и размышляет на тему будущего — в контексте проектов Panama и Sulong.
Мы подготовили текстовую версию доклада о работе с нативами в Java. В первой части:
Во второй части подробнее расскажем, какие есть варианты, что из них быстрее и лучше, и есть ли универсальная библиотека — всё с примерами кода и подсказками.
Далее — повествование от лица спикера.
Привет, меня зовут Сергеев Сергей aka gurugray. Сейчас я «Mentor FrontEnd Community» в компании ManyChat. Вы могли видеть мои лекции по релизному циклу и регламенту работ с системами контроля версий в Школе Разработки Интерфейсов Яндекса (ШРИ).
Меня часто спрашивают какие life-hacks или best-practices я использую при работе с Git'ом и репозиториями проекта.
Эта заметка — попытка объяснить те базовые настройки и приёмы, которыми я пользуюсь каждый день. Рецепты не претендуют быть ноу-хау, но могут помочь с освоением ежедневной гигиены работы с репозиторием.
Всё началось с короткого скрипта, который должен был объединить информацию об адресах e-mail сотрудников, полученных из списка пользователей почтовой рассылки, с должностями сотрудников, полученными из базы отдела кадров. Оба списка были экспортированы в текстовые файлы в кодировке Юникод UTF-8 и сохранены с юниксовскими концами строк.
Содержимое mail.txt
Иванов Андрей;ia@example.comСодержимое buhg.txt
Иванова Алла;маляр
Ёлкина Элла;крановщица
Иванов Андрей;слесарь
Абаканов Михаил;малярДля объединения файлы были отсортированы юниксовской командой sort и поданы на вход юниксовской программе join, которая неожиданно завершилась с ошибкой:
$> sort buhg.txt > buhg.srt
$> sort mail.txt > mail.srt
$> join buhg.srt mail.srt > result
join: buhg.srt:4: is not sorted: Иванов Андрей;слесарьПросмотр результата сортировки глазами показал, что в целом сортировка правильная, но в случае совпадений мужских и женских фамилий, женские идут перед мужскими:
$> sort buhg.txt
Абаканов Михаил;маляр
Ёлкина Элла;крановщица
Иванова Алла;маляр
Иванов Андрей;слесарьВыглядит как глюк сортировки в Юникоде или как проявление феминизма в алгоритме сортировки. Первое, конечно, правдоподобнее.