Kotlin Conf 2018
JetBrains выложили доклады с конференции — 56 качественных видео. Некоторые из них, которые мне были интересны: Kotlin and Spring Boot, Best practices for Unit testing, Kotlin Coroutines, Functional programming in Kotlin, Kotlin Pazzlers.
https://www.youtube.com/playlist?list=PLQ176FUIyIUbVvFMqDc2jhxS-t562uytr
#kotlin
JetBrains выложили доклады с конференции — 56 качественных видео. Некоторые из них, которые мне были интересны: Kotlin and Spring Boot, Best practices for Unit testing, Kotlin Coroutines, Functional programming in Kotlin, Kotlin Pazzlers.
https://www.youtube.com/playlist?list=PLQ176FUIyIUbVvFMqDc2jhxS-t562uytr
#kotlin
Работа в Epam
Я уже публиковал пост про работу в банках https://yangx.top/java_developer/81. В этот раз пишу об аутсорсинг-компании Епам. У меня много знакомых работает в Епаме. Кому-то не нравится, кто-то ушел, а кому-то в кайф, и они работают в удовольствие. По общению с ними, я понял, что многое зависит от проекта и людей, которые на нём работают. Например, есть молодые интересные проекты — крутой современный стек и опытные архитекторы, есть иностранные — постоянное общение на английском и возможные командировки. А есть банковские проекты с доисторическими технологиями или просто говнопроекты, которые заказчики отдали на аутсорс, потому что сами не хотят в этом ковыряться.
На Хабре вышла статья системного архитектора, которому, как я думаю, не повезло. Сначала он думал, что останется в Епаме надолго, но скоро уволился. Вот его основная мысль:
«Я ушел из Епама из-за ощущения, что не работаю, а занимаюсь имитацией деятельности. Приходить можно когда угодно, главное не пропускать митинги. Причем, не пропускать лишь потому, что митинги выглядят как митинги ради самого митинга, где главное – собрать тусовку для "если кто из руководства посмотрит сверху". Чтобы солидно, и чтобы на английском. Гонять балду очень просто, если ты хоть немного в теме. Можешь сидеть на проекте или вне его. Если будешь болтаться вне проекта, это нестрашно. Тебя запишут на какой-нибудь фейковый проект, чтобы "взгляд сверху" не заметил что-то не то.
И все это создает ощущение какой-то матрицы. Вроде все при деле, но если тебя в этом деле не будет, то ничего не изменится. Помню, как я был рад, что меня взяли в ЕПАМ. Помню свои первые дни и недели, и недоумение, когда видел увольняющихся. Помню, спросил коллегу, который работал последний день, почему он уходит. И получил ответ, что тут все неторопливо, все как-то очень вяло. Через какое-то время я это прочувствовал. Да, грустно, когда ты не летишь на работу, потому что там ты нужен и без тебя никак. Неприятно осознать и даже услышать, что ты ну как бы никто и будешь делать то, что нужно компании, т.к. ты просто ресурс компании без права на мнение. Но гораздо хуже ощущать себя имитацией, которой вообще не существует.»
Сама статья: https://habr.com/post/429870/
Друзья, хороших выходных вам, крутых проектов и достойных коллег!
Я уже публиковал пост про работу в банках https://yangx.top/java_developer/81. В этот раз пишу об аутсорсинг-компании Епам. У меня много знакомых работает в Епаме. Кому-то не нравится, кто-то ушел, а кому-то в кайф, и они работают в удовольствие. По общению с ними, я понял, что многое зависит от проекта и людей, которые на нём работают. Например, есть молодые интересные проекты — крутой современный стек и опытные архитекторы, есть иностранные — постоянное общение на английском и возможные командировки. А есть банковские проекты с доисторическими технологиями или просто говнопроекты, которые заказчики отдали на аутсорс, потому что сами не хотят в этом ковыряться.
На Хабре вышла статья системного архитектора, которому, как я думаю, не повезло. Сначала он думал, что останется в Епаме надолго, но скоро уволился. Вот его основная мысль:
«Я ушел из Епама из-за ощущения, что не работаю, а занимаюсь имитацией деятельности. Приходить можно когда угодно, главное не пропускать митинги. Причем, не пропускать лишь потому, что митинги выглядят как митинги ради самого митинга, где главное – собрать тусовку для "если кто из руководства посмотрит сверху". Чтобы солидно, и чтобы на английском. Гонять балду очень просто, если ты хоть немного в теме. Можешь сидеть на проекте или вне его. Если будешь болтаться вне проекта, это нестрашно. Тебя запишут на какой-нибудь фейковый проект, чтобы "взгляд сверху" не заметил что-то не то.
И все это создает ощущение какой-то матрицы. Вроде все при деле, но если тебя в этом деле не будет, то ничего не изменится. Помню, как я был рад, что меня взяли в ЕПАМ. Помню свои первые дни и недели, и недоумение, когда видел увольняющихся. Помню, спросил коллегу, который работал последний день, почему он уходит. И получил ответ, что тут все неторопливо, все как-то очень вяло. Через какое-то время я это прочувствовал. Да, грустно, когда ты не летишь на работу, потому что там ты нужен и без тебя никак. Неприятно осознать и даже услышать, что ты ну как бы никто и будешь делать то, что нужно компании, т.к. ты просто ресурс компании без права на мнение. Но гораздо хуже ощущать себя имитацией, которой вообще не существует.»
Сама статья: https://habr.com/post/429870/
Друзья, хороших выходных вам, крутых проектов и достойных коллег!
Java Developer via @vote
Ситуация — вы в поиске работы. Характеристика, которая больше остальных повлияет на выбор компании:
anonymous poll
Зарплата выше средней – 504
👍👍👍👍👍👍👍 56%
Возможность переехать в другой город/страну – 209
👍👍👍 23%
Удалённая работа – 108
👍👍 12%
Офис недалеко от дома – 47
👍 5%
Красивый офис – 21
▫️ 2%
Оплачиваемая медицинская страховка – 13
▫️ 1%
👥 902 people voted so far.
anonymous poll
Зарплата выше средней – 504
👍👍👍👍👍👍👍 56%
Возможность переехать в другой город/страну – 209
👍👍👍 23%
Удалённая работа – 108
👍👍 12%
Офис недалеко от дома – 47
👍 5%
Красивый офис – 21
▫️ 2%
Оплачиваемая медицинская страховка – 13
▫️ 1%
👥 902 people voted so far.
Пробуйте. Общайтесь. Кайфуйте
Я недавно был на презентации книги Ирины Хакамады. Не спрашивайте, как туда попал. Запомнил несколько мыслей, которые можно перенести и на наши будни:
«Общаюсь с молодыми бизнесменами-миллионерами. Зелёные — 22 года. Но как начнешь с ними говорить про деньги, процессы, бизнес, то понимаешь, что они очень уверенно, умно и по-взрослому мыслят. Всё потому что, много пробовали, запускали новые проекты».
Так же и нам нужно пробовать постоянно что-то новое, использовать интересные технологии, создавать никому ненужные приложения, проекты. А там глядишь и выстрелят.
«Главный минус современной молодежи, что она не умеет коммуницировать. Деньги, идеи есть, но нет умения договариваться.»
Мы с вами, как программисты, часто себя считаем самодостаточными. И это правильно с точки зрения психологии. Но когда хочешь расти как спец, важно еще постоянно общаться с коллегами, спрашивать совета у более опытных товарищей, обсуждать технологии.
«Я постоянно задаю себе вопрос что бы такого афигенного сделать, чтобы мне понравилось. А потом остальным. Причем остальным необязательно.»
Думаю нужно делать всё в кайф. Если делать что-то без удовольствия, то должного эффекта не видать. А когда делаешь с желанием, с удовольствием, то и результат приходит намного быстрее. Короче, если кодить, то с кайфом!
Я недавно был на презентации книги Ирины Хакамады. Не спрашивайте, как туда попал. Запомнил несколько мыслей, которые можно перенести и на наши будни:
«Общаюсь с молодыми бизнесменами-миллионерами. Зелёные — 22 года. Но как начнешь с ними говорить про деньги, процессы, бизнес, то понимаешь, что они очень уверенно, умно и по-взрослому мыслят. Всё потому что, много пробовали, запускали новые проекты».
Так же и нам нужно пробовать постоянно что-то новое, использовать интересные технологии, создавать никому ненужные приложения, проекты. А там глядишь и выстрелят.
«Главный минус современной молодежи, что она не умеет коммуницировать. Деньги, идеи есть, но нет умения договариваться.»
Мы с вами, как программисты, часто себя считаем самодостаточными. И это правильно с точки зрения психологии. Но когда хочешь расти как спец, важно еще постоянно общаться с коллегами, спрашивать совета у более опытных товарищей, обсуждать технологии.
«Я постоянно задаю себе вопрос что бы такого афигенного сделать, чтобы мне понравилось. А потом остальным. Причем остальным необязательно.»
Думаю нужно делать всё в кайф. Если делать что-то без удовольствия, то должного эффекта не видать. А когда делаешь с желанием, с удовольствием, то и результат приходит намного быстрее. Короче, если кодить, то с кайфом!
Английский не выходя из дома
Подглядел в приложении Тинькофф онлайн-ресурсы для изучения английского. Подкасты, фильмы, курсы, общение с носителями — всё, как надо.
Подглядел в приложении Тинькофф онлайн-ресурсы для изучения английского. Подкасты, фильмы, курсы, общение с носителями — всё, как надо.
JavaDoc
JavaDoc — cпециальные комментарии, которые предназначены для документирования Java-кода. С помощью этих комментариев можно описывать классы, интерфейсы, переменные, методы, пакеты. Хороший JavaDoc помогает новым пользователям быстро разобраться с библиотекой, с которой он не знаком.
Лучшие примеры JavaDoc — исходники самой Джавы. В каждом классе подробно описано, что делают и чего не делают методы, при каких условиях они работают, и как они справляются с ошибками. В общем, хорошая документация та, после которой не нужно гуглить туториалы или подходить к человеку, который её написал.
JavaDoc — cпециальные комментарии, которые предназначены для документирования Java-кода. С помощью этих комментариев можно описывать классы, интерфейсы, переменные, методы, пакеты. Хороший JavaDoc помогает новым пользователям быстро разобраться с библиотекой, с которой он не знаком.
Лучшие примеры JavaDoc — исходники самой Джавы. В каждом классе подробно описано, что делают и чего не делают методы, при каких условиях они работают, и как они справляются с ошибками. В общем, хорошая документация та, после которой не нужно гуглить туториалы или подходить к человеку, который её написал.
Старт карьеры
Попросил своего друга Павла Погодаева @pogpp описать впечатления от первых двух недель работы программистом. В итоге получился небольшой рассказ о его первом месте работы. Слово Паше:
Первые дни работы программистом.
Год-полтора учёбы и подготовки к интервью, и вот он – оффер в не самую отстойную контору. Девочка-кадровик собирает бумаги, а ты ходишь очаровано смотришь на средний офис, команду разработки и переживаешь про себя. Вдруг ты самозванец, тебя спалят, что приврал в резюме про Spring Boot или Hibernate и не пройдешь испыталку. Но нет.
Начало везде одинаковое: читаешь бесполезную документацию, смотришь видосы, ни у кого особо на тебя нет времени. Но потом приходит она – первая таска. Как правило, простая, как 2 байта переслать. Через пару месяцев уже полноценно участвуешь в работе, несёшь ответственность за фичи и в целом появляется картина, как оно и зачем.
Моим первым проектом на пути программиста были кассовые приложения для Спортмастера. Из технологий – Hibernate, JavaFX + guice и божественный soap для связи с внешними системами. Через 7 месяцев я прозрел, что это сплошной багфикс и никакого роста. Стояк на работу стал не так крепок, и пришло время что-то менять. Как итог: новая приятная работа, доходы выросли за год в 2.5 раза, международный проект, переезд из Мск в СПб (да-да, не надо стесняться релоцироваться из-за денег) и вот оно счастье.
Попросил своего друга Павла Погодаева @pogpp описать впечатления от первых двух недель работы программистом. В итоге получился небольшой рассказ о его первом месте работы. Слово Паше:
Первые дни работы программистом.
Год-полтора учёбы и подготовки к интервью, и вот он – оффер в не самую отстойную контору. Девочка-кадровик собирает бумаги, а ты ходишь очаровано смотришь на средний офис, команду разработки и переживаешь про себя. Вдруг ты самозванец, тебя спалят, что приврал в резюме про Spring Boot или Hibernate и не пройдешь испыталку. Но нет.
Начало везде одинаковое: читаешь бесполезную документацию, смотришь видосы, ни у кого особо на тебя нет времени. Но потом приходит она – первая таска. Как правило, простая, как 2 байта переслать. Через пару месяцев уже полноценно участвуешь в работе, несёшь ответственность за фичи и в целом появляется картина, как оно и зачем.
Моим первым проектом на пути программиста были кассовые приложения для Спортмастера. Из технологий – Hibernate, JavaFX + guice и божественный soap для связи с внешними системами. Через 7 месяцев я прозрел, что это сплошной багфикс и никакого роста. Стояк на работу стал не так крепок, и пришло время что-то менять. Как итог: новая приятная работа, доходы выросли за год в 2.5 раза, международный проект, переезд из Мск в СПб (да-да, не надо стесняться релоцироваться из-за денег) и вот оно счастье.
Хорошо — Плохо
Проглатывать исключения плохая практика
Плохо
Хорошо
Тоже гуд
Проглатывать исключения плохая практика
Плохо
catch (Exception ignored) {}Хорошо
catch (Exception e) { throw new RuntimeException(e);}Тоже гуд
catch (Exception e) { log.error("Description", e);}Один из лучших вариантов пробрасывания ислкючения — создать свой специализированный. Например, UserNotFoundException, который унаследован от RuntimeException. Плюс обрабатывать исключение должен тот класс, который знает, что с ним нужно делать. Иначе прокидывать дальше.
Исключения нужно использовать только для сигнализации исключительных ситуаций и не использовать для корректного исполнения. Они намного дороже с точки зрения ресурсов, чем обычный возврат значения или управления.
Исключения нужно использовать только для сигнализации исключительных ситуаций и не использовать для корректного исполнения. Они намного дороже с точки зрения ресурсов, чем обычный возврат значения или управления.
Хорошо — Плохо
Объявляйте переменные в как можно меньшей области видимости. Например, переменная
Плохо
Хорошо
Плохо
Хорошо
Объявляйте переменные в как можно меньшей области видимости. Например, переменная
i используется только внутри цикла. Её нужно объявить внутри цикла, а не снаружи.Плохо
int i = 0;for (i = 0; i < 10; i++) { /* ... */}Хорошо
for (int i = 0; i < 10; i++) { /* ... */}Плохо
int count = 0;void counter() { if (count++ > 10) { return; } /* ... */}Хорошо
void counter() { int count = 0; if (count++ > 10) { return; } /* ... */}Хорошо — Плохо
Везде, где это возможно, объявление и инициализацию переменной записывайте в одну строку. И каждую переменную объявляйте отдельной строкой. То есть не нужно использовать объявления такого типа
Плохо
Хорошо
Везде, где это возможно, объявление и инициализацию переменной записывайте в одну строку. И каждую переменную объявляйте отдельной строкой. То есть не нужно использовать объявления такого типа
int a, b;Плохо
int i, j;i = j = 100;Хорошо
int i = 100;int j = 100;Кто такой CTO
Задал несколько вопросов Фёдору Борщёву, CTO в ГдеМатериал и автору канала @pmdaily.
— Расскажи, как прошел свой путь от простого программиста до технического директора
Я работал в небольшом провинциальном веб-агенстве. Там достаточно быстро начал руководить всей командой разработки. Думаю, это не было моей заслугой — просто в компании было тяжело с людьми, которые одновременно умеют брать на себя ответственность и понимать, как работают технические штуки.
В какой-то момент я осознал, что у меня хорошо получается самостоятельно прокачиваться в хард-скиллах, но вот с софт-скиллами вообще ничего не происходит. Взвесил себя на рынке труда и понял, что со своим балансом знаний я не подхожу ни для чего кроме скучной работы низкопробного веб-программиста, и немного приуныл.
Тогда я и решил на какое-то время завязать с программированием, перебрался в Москву и пошел в студию Лебедева руководить дизайн-проектами. Студия — место с особой атмосферой и особенными людьми. Думаю, именно студия дала мне то, чего не хватало, чтобы стать CTO.
За время редких студийных выходных я выучил Django и сопутствующий стек (до этого писал на PHP). И под конец работы в студии начали сыпаться предложения об интересных технически-сложных проектах.
— Чем занимается CTO?
С точки зрения бизнеса, первая задача CTO — сделать работу с техническими специалистами такой же управляемой как, скажем, с менеджерами по продажам. Бизнес не должен задумываться о том, сколько у него программистов, на каких технологиях они работают, какое у них покрытие кода тестами и объем технического долга. Вместо этого он должен выдавать требования, получать в ответ цифры ФОТ (оплата труда) и результат к заявленному сроку.
Дальше начинается специфика — в маленьких компаниях CTO должен быть мастером на все руки. И в продукт влезть не хуже продакт-менеджера, и код пописать на уровне синьора, и бизнесу рассказать, какие требования лучше отдать в разработку, а какие сделать по старинке на Экселе и AmoCRM.
В больших компаниях, наоборот, CTO становится ближе к администрированию — выбирает правильных подрядчиков, задает им бизнесовые KPI, обращает много внимания на HR — как делить команды (по продуктам? по компетенциям? по фичам?), кого ставить во главу этих команд, как нанимать правильных людей и организовать передачу знаний.
Кроме бизнеса «сверху», есть еще программисты. Программисты обычно ждут от CTO хороших процессов — все хотят получать четко поставленные задачи с четкими критериями приемки, работать на актуальных технологиях, иметь возможность самим принимать решения и расплачиваться с техническом долгом, знать у кого из коллег о чем стоит спросить и т.д. В общем задача CTO для программистов — сделать, чтобы они были счастливыми, а значит — производительными.
— Насколько глубоко CTO должен разбираться в языках программирования? И какие технологии должен знать?
Для маленьких компаний, где CTO «работает руками», чем больше технологий — тем лучше :-) Лично я стараюсь фокусироваться на том, что важно для комфортной и быстрой работы команды, но при этом тяжело дается для изучения на «боевых» задачах — девопс, новые инструменты\механики тестирования, какие-то вещи про будущее.
Кроме самих технологий, CTO должен понимать, куда движется рынок в целом. Скажем года два назад хороший CTO для JS-проектов должен был изучать такие популярные сейчас вещи как Vue.js, typescript, jest, задумываться о serverless, знакомиться с netlify, предсказывать, что хайп вокруг NoSQL сойдет на нет и т.д.
А для больших компаний желание работать руками скорее будет минусом, чем плюсом.
#интервью #cto
Задал несколько вопросов Фёдору Борщёву, CTO в ГдеМатериал и автору канала @pmdaily.
— Расскажи, как прошел свой путь от простого программиста до технического директора
Я работал в небольшом провинциальном веб-агенстве. Там достаточно быстро начал руководить всей командой разработки. Думаю, это не было моей заслугой — просто в компании было тяжело с людьми, которые одновременно умеют брать на себя ответственность и понимать, как работают технические штуки.
В какой-то момент я осознал, что у меня хорошо получается самостоятельно прокачиваться в хард-скиллах, но вот с софт-скиллами вообще ничего не происходит. Взвесил себя на рынке труда и понял, что со своим балансом знаний я не подхожу ни для чего кроме скучной работы низкопробного веб-программиста, и немного приуныл.
Тогда я и решил на какое-то время завязать с программированием, перебрался в Москву и пошел в студию Лебедева руководить дизайн-проектами. Студия — место с особой атмосферой и особенными людьми. Думаю, именно студия дала мне то, чего не хватало, чтобы стать CTO.
За время редких студийных выходных я выучил Django и сопутствующий стек (до этого писал на PHP). И под конец работы в студии начали сыпаться предложения об интересных технически-сложных проектах.
— Чем занимается CTO?
С точки зрения бизнеса, первая задача CTO — сделать работу с техническими специалистами такой же управляемой как, скажем, с менеджерами по продажам. Бизнес не должен задумываться о том, сколько у него программистов, на каких технологиях они работают, какое у них покрытие кода тестами и объем технического долга. Вместо этого он должен выдавать требования, получать в ответ цифры ФОТ (оплата труда) и результат к заявленному сроку.
Дальше начинается специфика — в маленьких компаниях CTO должен быть мастером на все руки. И в продукт влезть не хуже продакт-менеджера, и код пописать на уровне синьора, и бизнесу рассказать, какие требования лучше отдать в разработку, а какие сделать по старинке на Экселе и AmoCRM.
В больших компаниях, наоборот, CTO становится ближе к администрированию — выбирает правильных подрядчиков, задает им бизнесовые KPI, обращает много внимания на HR — как делить команды (по продуктам? по компетенциям? по фичам?), кого ставить во главу этих команд, как нанимать правильных людей и организовать передачу знаний.
Кроме бизнеса «сверху», есть еще программисты. Программисты обычно ждут от CTO хороших процессов — все хотят получать четко поставленные задачи с четкими критериями приемки, работать на актуальных технологиях, иметь возможность самим принимать решения и расплачиваться с техническом долгом, знать у кого из коллег о чем стоит спросить и т.д. В общем задача CTO для программистов — сделать, чтобы они были счастливыми, а значит — производительными.
— Насколько глубоко CTO должен разбираться в языках программирования? И какие технологии должен знать?
Для маленьких компаний, где CTO «работает руками», чем больше технологий — тем лучше :-) Лично я стараюсь фокусироваться на том, что важно для комфортной и быстрой работы команды, но при этом тяжело дается для изучения на «боевых» задачах — девопс, новые инструменты\механики тестирования, какие-то вещи про будущее.
Кроме самих технологий, CTO должен понимать, куда движется рынок в целом. Скажем года два назад хороший CTO для JS-проектов должен был изучать такие популярные сейчас вещи как Vue.js, typescript, jest, задумываться о serverless, знакомиться с netlify, предсказывать, что хайп вокруг NoSQL сойдет на нет и т.д.
А для больших компаний желание работать руками скорее будет минусом, чем плюсом.
#интервью #cto