Успели во время самоизоляции стать суперэффективными и освоить пару новых специальностей? Тоже нет? А ведь все вокруг трубили: «Используй это время с пользой! Кризис – всегда точка роста». Оказывается, это совершенно нормально, если вы не нашли в себе сил начать осваивать новый язык программирования или вышивание гладью. Психологи говорят, что сильный и продолжительный стресс вредит обучению, а мы все это время прожили в условии постоянно меняющихся правил. Однако хватит «выученной беспомощности», впереди еще много перемен, и суперэффективность нам может пригодиться. 

Я поговорила с преподавателями «Сетевой Академии» (кстати, нашему учебному центру 30 августа исполняется 25 лет!), чтобы узнать, что они думают про обучение дома, и собрала все мысли в этом посте: действительно ли это было время возможностей? Что поможет обучению, если всё вокруг мешает процессу? Чему и где учиться онлайн? Они дали свои рекомендации и рассказали о достойных образовательных платформах.

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

Вы изучили команды Git но хотите представлять, как непрерывная интеграция (Continuous Integration, CI) происходит в реальности? Или может вы хотите оптимизировать свои ежедневные действия? Этот курс даст вам практические навыки непрерывной интеграции с использованием репозитория на GitHub. Данный курс не задуман как некий визард, который можно просто прокликать, напротив, вы будете совершать те же действия, что люди на самом деле делают на работе, тем же способом, которым они это делают. Я буду объяснять теорию по мере прохождения вами имеющих к ней отношение шагов.

Что мы будем делать?

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

Этот GIF схематично показывает коммиты в вашем репозитории по мере продвижения по курсу. Как видите, тут нет ничего сложного и только самое необходимое.

Вы пройдёте такие стандартные для CI сценарии:

• Работа над фичей;
• Применение автотестов для обеспечения качества;
• Реализация приоритетной задачи;
• Разрешение конфликта при слиянии ветвей (merge conflict);
• Возникновение ошибки в продуктивной среде.

Повторяться, но каждый раз по-новому – разве не это есть искусство?

Станислав Ежи Лец, из книги «Непричёсанные мысли»

Словарь определяет репликацию как процесс поддержания двух (или более) наборов данных в согласованном состоянии. Что такое «согласованное состояние наборов данных» – отдельный большой вопрос, поэтому переформулируем определение проще: процесс изменения одного набора данных, называемого репликой, в ответ на изменения другого набора данных, называемого основным. Совсем не обязательно наборы при этом будут одинаковыми.



Поддержка репликации баз данных – одна из важнейших задач администратора: почти у каждой сколько-нибудь важной базы данных есть реплика, а то и не одна.

Среди задач, решаемых репликацией, можно назвать как минимум

• поддержку резервной базы данных на случай потери основной;
• снижение нагрузки на базу за счёт переноса части запросов на реплики;
• перенос данных в архивные или аналитические системы.

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

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

Привет всем, друзья!

* Эта статья написана по мотивам открытого практикума REBRAIN & Yandex.Cloud, если вам больше нравится смотреть видео, можете найти его по этой ссылке — https://youtu.be/cZLezUm0ekE

Недавно нам представилась возможность пощупать вживую Яндекс.Облако. Поскольку щупать хотелось долго и плотно, то мы сразу отказались от идеи запуска простого wordpress блога с облачной базой — слишком скучно. После непродолжительных раздумий решили развернуть что-то похожее на продакшн архитектуру сервиса для приема и анализа ивентов в near real time режиме.

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

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

Грамотно выстроенная коммуникация и хорошо организованное распространение информации на проекте — самые важные условия для слаженной работы команды. Думаю, во всех командах, вне зависимости от того, remote они или нет, сталкивались с проблемами вида “А почему мне не сказали”, “Но мы же договаривались о другом” или “Блин, я не увидел”. К сожалению, нельзя полностью избежать возникновения таких ситуаций. Но можно свести вероятность их возникновения к минимуму. В этой статье я расскажу о том, какими правилами коммуникации и настройками мессенджера мы эти проблемы решили.

Передача составных данных методом POST

В жизни любого программиста попадаются задачки, которые человека цепляют. Вот не нравится стандартный метод решения и все! А порой бывает, что стандартные решения не подходят по какой-то причине. Некоторые люди обходят такие задачи стороной, другие же любят решать их. Можно даже сказать сами их находят. Одна из таких задач отсылка файла или несколько файлов методом POST.

Некоторые наверное скажут, эта задача совсем не задача. Ведь есть замечательная библиотека CURL, которая довольно простая и решает эту задачу легко! Но не спешите. Да, CURL мощная библиотека, да она загружает файлы, но… Как Вы знаете у нее есть маленькая особенность — файл должен быть размещен на жестком диске!

Предлагаем вам перевод поста «Unit Testing is Overrated» от Alex Golub, чтобы подискутировать на тему юнит-тестов. Действительно ли они переоценены, как считает автор, или же являются отличным подспорьем в работе? Опрос — в конце поста

Результаты использования юнит-тестов: отчаяние, мучения, гнев

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

В процессе развития отрасли разработки ПО совершенствовались и методики тестирования. Они постепенно сдвигались в сторону автоматизации и повлияли на саму структуру ПО, порождая такие «мантры», как «разработка через тестирование» (test-driven development), делая упор на такие паттерны, как инверсия зависимостей (dependency inversion), и популяризируя построенные на их основе высокоуровневые архитектуры.

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

Однако, несмотря на существование различных подходов, современные «best practices» в основном подталкивают разработчиков к использованию конкретно юнит-тестирования. Тесты, область контроля которых находится в пирамиде Майка Кона выше, или пишутся как часть более масштабного проекта (часто совершенно другими людьми), или полностью игнорируются.

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

В этой статье рассматривается создание достаточного простого автотеста. Статья будет полезна начинающим автоматизаторам.

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

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

Я подумал — ну окей, так, наверное, бывает не всегда. С тех пор прошло лет 5, я не раз менял работу, но везде и всегда созвоны были пустой тратой времени.

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

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

Собрал для вас цитаты из разных книг по важной, на мой взгляд, теме: что нужно для изменений – инструкция или принципы.

Несмотря на всю абсурдность идеи брать чей-нибудь готовый кейс и использовать его у себя, именно так и поступают менеджеры в большинстве случаев. Это вполне объяснимо: сделать по инструкции проще, чем брать какие-то принципы, кубики, и лепить из них собственный кейс, с учетом особенностей своей компании. А главное: за результат отвечать не надо. Если не сработало, то виноват кейс. Так появляются тысячи статей, постов, видео и выступлений о неэффективности повышения эффективности.

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

Цитаты я собрал для нас – «глобусов», на которых «натягивают сову». Большинство книг, из которых взяты цитаты, входят в обязательный менеджерский набор. Так что можно крыть их же козырями.

Некоторые цитаты длинноваты — не хотел прерывать авторов, вырывать мысль из контекста.

Телеграмму накатал:

«Шлите денег — отбатрачу,
Я их все прохохотал».

_{/В.Высоцкий/}

Тот, кто впервые выходит на фондовый рынок как частный инвестор, сразу думает о двух активах: акциях и валюте. Эти инструменты кажутся простыми и прозрачными. Но если бы всё было так просто, эту статью писал бы долларовый миллионер для долларовых миллионеров. Акции — инструмент коварный и крайне непростой, он требует профессионального подхода и не прощает ошибок. Это уже далеко не те случаи, которые показывают в захватывающих фильмах про биржевиков XX века — это фондовый рынок 2020. Даже первый шаг должен быть очень серьёзным.

Источник

Аналитика рынка разработчиков и CTO:

• Сколько денег хотят разработчики и CTO, которые не ищут работу и как можно их замотивировать
• 4 ключевых причины, которые могут снижать стоимость разработчиков и что может повышать их ценность;
• 12 факторов, с помощью которых вы можете заинтересовать опытных экспертов;
• Могут ли кандидаты стоить для вас дешевле. Что делать, если у вас проблемы с наймом. Как кризис и пандемия повлияли на хантинг. Общие рекомендации современного хантинга.

Начальник заставляет работать по ночам или в выходные? Орёт при всех матом? Позволяет себе пошлые шутки? Коллеги постоянно и настоятельно требуют помощи? Премию так и не дают, а зарплату не повышают? Ваше возмущение вызывает, в лучшем случае, смех?

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

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

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


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

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

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

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

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

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

2,4 ГГц — это плохо. 5 ГГц — это хорошо. 6 ГГц — это ещё лучше, но послезавтра. Все это знают, кого я тут учу, в самом деле. Всё это хорошо, только делать-то что, когда ты такой, как умный, открываешь какой-нибудь Wi-Fi Explorer, а там сатанизм и этажерки, как на скриншоте?



Шаг первый — поплакать. Шаг второй — нырнуть под кат. Вопрос простой, а ответ — нет.

Привет, Хаброжители! Хотите повысить свою эффективность в разработке корпоративных и облачных Java-приложений?

Увеличьте скорость и простоту разработки микросервисов и сложных приложений, избавившись от забот по конфигурации Spring.

Используйте Spring Boot 2 и такие инструменты фреймворка Spring 5, как WebFlux, Security, Actuator, а также фреймворк Micrometer, предоставляющий новый способ сбора метрик.

Как и любой здоровый человек — могу назвать себя в меру ленивым.

Так, например, мне лень писать длинный pipeline (вообще писать руками pipeline лень). И мне не нравится идея гонять туда — сюда файлик, в который придётся писать параметры, для чего городить огород из лишнего кода.

Кстати, может кто-то из читателей этой статьи сможет объяснить, почему нужно выполнять все операции (сборка дистрибутива, его тестирование и т. д.) на той же машине, где расположен Jenkins? Я вот так не считаю и моя архитектура построена так, что Jenkins нужен для запуска задач, а вот они (задачи) выполняются на отведённых под эти вещи машинах. Но это лирика и желание пообщаться и поделиться опытом.

Сама статья о другом: как сохранить параметры и параметризовать регулярную Job'у удобно и штатно?

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

Вы уже сделали некоторою Job'у, с использованием плагина Active Choices и теперь вы молодцы и можете запускать руками нужный набор.

Но как теперь объединить обе этих функции, чтобы получить выгоду от обоих подходов?
Не буду рассказывать всех тех вариантов, которые мне пришлось услышать или попробовать, а сразу перейду к самой сути. Решение моё лишь частично, так как реализация была найдена на Medium. Я же решил поделиться им с сообществом, чтобы больше людей перестали костылить и делать глупости.