Блог Хекслета

Не используйте чек-боксы в пользовательских интерфейсах. Используйте переключатели (radio buttons). У чек-боксов есть одно преимущество: они занимают меньше пространства. Но у них есть и серьезный недостаток: часто неясно, что значит неотмеченный чекбокс.

Вот несколько примеров. Первый — из формы настроек WillMaker от Quicken (сервиса для планирования наследственного фонда в США):

[ ] Отсортировать список контактов по фамилии
Quicken WillMaker отобразит контакты в списке, отсортированные по фамилии)

Понятно, что если чекбокс отмечен, список контактов будет отсортирован по фамилии. Но как он будет отсортирован, если чекбокс будет пустым? Очевидно, они обнаружили, что у пользователей возникли проблемы с этой позицией, потому что встроили в список справочный текст, но объяснение просто перефразировало предложение у чек-бокса. Лучше переделать, используя переключатели:

О том, чем отличается путь Java-разработкчика (и других JVM-языков) от пути разработчиков на других языках и платформах, как развиваться профессионально в условиях работы на крупных проектах.

Мы рассмотрим в обзорном порядке, какая она - карьера программиста, в применении к Java-технологиям. Какие основные проблемы наблюдаются на этом пути, какие личные качества помогут Вам в работе, какие soft-skill'овые и технические навыки необходимы и будут плюсом для успешной карьеры.

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

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

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

Я часто ловлю себя за чтением и изучением чего-то нового, потому что я любопытный человек. Я прочитал книгу «A Mind for Numbers» Барбары Оукли, чтобы улучшить и перевести на новый уровень процесс своего обучения. Этот пост – моя выдержка из книги. Тут содержится десять наиболее важных моментов, которые, как я думаю, те, кто изучает что-то новое, должны применять на практике.

Cиндром самозванца – это реальная штука, и он поражает новых разработчиков. Мы проходим через туториалы, буткемпы или даже полноценное университетское образование, но всё равно стесняемся делиться своим кодом. Мы боимся плохой оценки качества нашего кода. Никто не страдает от этого сильнее разработчиков с самообразованием. Поскольку у нас нет «фактического» или «задокументированного» опыта или мы не стажировались, мы оцениваем свой код ниже среднего.

Несколько месяцев назад я был таким. Я перечитывал Test-Driven Development With Python Гарри Персиваля. Несмотря на то, что всё делал по книге, я стеснялся делиться своим кодом. Пусть моё приложение и работало так, как было задумано, я не хотел делиться прогрессом. Я не хотел, чтобы кто-то указал мне на какую-то очевидную ошибку, на которую я не обратил внимание. Я хотел, чтобы мой продукт приносил удовольствие другим людям, но не хотел, чтобы они видели, насколько я слабый разработчик.

Я отложил свой проект, и после недолгой паузы стал просматривать другие проекты на GitHub. Я нашёл несколько, у которых был маленький значок на страницах README.

Как настоящий чайник, я подумал, что это просто картинка, которую Линус Торвальдс выдаёт на флешке, когда вы заканчиваете школу "Настоящего разработчика". Мне ни разу не приходило в голову щёлкнуть по ней. Я думал, что это статическая картинка, размещённая где-то в репозитории. Позже я наткнулся на проект, который показывал, что билд провалился.

Почему кто-то потратил время на то, чтобы добавить изображение, на котором говорится, что их билд не удался?

Начну свою историю с рассказа о том как я познакомился с веб разработкой.

Всё началось на 1 курсе института. Мне было скучно в общаге, программа была легкой (я учусь на специальности "Мехатроника и робототехника") и у меня была куча свободного времени. И в один прекрасный день мне в глаза бросилась реклама различных курсов программирования на сайте codecademy.

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

Публичное собеседование: Демид Каширин

Я размышляю о последствиях «неправильной абстракции». Мой доклад с RailsConf 2014 «all the little things» включал раздел, в котором я высказала такое мнение:

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

А заключение я подытожила советом:

выбирайте дублирование вместо неправильной абстракции

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

This, a million times this! “@BonzoESC: “Duplication is far cheaper than the wrong abstraction” https://twitter.com/pims/status/442010383725760512

Если вы хотите больше практических заданий и владеете английским (или хотя бы умеете гуглить перевод), то у меня для вас хорошая новость! Пару дней назад Кирилл подсказал неплохой сайт-тренажер-задачник. Я его опробовал, и, вот, теперь опишу свои мысли. Ах да, сервис называется codewars и наверняка кто-то из вас уже слышал о нем.

Коротко о коудворс

Для меня лично codewars стал местом, где можно попрактиковать технику написания кода + узнать чужие, более интересные техники. Сервис реализован в стиле "восточных единоборств". Сам сайт уже не просто сайт, а – додзё; задачки – ката; вы – солдат, воин, а не просто студент-программист, а код-ревью – кумите, спарринг. Восточная тематика создает специфическую атмосферу – здесь хочется непрерывно развиваться и становиться искуссным мастером. Порадовала сегментация задачек-ката по сложности. В общем, заходи и развивайся, самурай!

Июльский дайджест... Что-то подобное уже случалось на Хекслете год назад. Теперь надеемся это войдет в традицию и будет полезным для вас. Пожалуйста, оставьте свой фидбек: интересны ли вам подобные дайджесты, что я упустил, какие темы и новости вам интересны больше всего?

Работу джунам!

Понимаем как сложно некоторым начать карьеру. Непонятно что делать, да и вообще когда начинать поиски. Для этой цели мы внедрили новую фичу: Добро пожаловать в раздел "Карьера". Это не просто набор открытых вакансий для новичков (джуниоров) как это может показаться с первого взгляда. Фича многосоставная, двухсложная...

JavaScript быстро эволюционирует в последнее время, но не то, чтобы другие языки веб-разработки стояли на месте.

CSS тоже развивается, и скорее всего Houdini совершит новый прорыв в CSS, но его, к сожалению, адаптируют далеко не все. Мы всё так же проходим процесс совещаний специалистов, которые создают новые спецификации и всё такое… Не так, как с непрерывными изменениями стандарта TC39, но всё же.

Вы вероятно слышали но, скорее всего — нет! о единицах измерения в CSS, речь о которых пойдёт в этой статье. И нет, не о тех, «старых» vw и vh (которые предстоит объяснить тем, кто меньше разбирается в CSS).

Ниже перечислены новые единицы CSS, которые будут детально описаны в готовящемся CSS Value и Units Module Level 4.

Первая моя айтишная работа - эникейщик в большой компании, из которой в последствии свалили все, кто имел хоть какое-то чистолюбие. Через год я стал старшим эникейщиком. Её через год ушел в админы. Ещё через 6 лет из 8-и в качестве админа я начал учиться программить

Вы часто слышите разное об Искусственном интеллекте (AI), Машинном обучении (ML) и даже Глубоком обучении (DL). Как и что правильно называть? Может это одно и то же? Люди постоянно подменяют эти термины.

Сидел, смотрел собеседование с новым участником по имени Дима, попивая чай с печеньками. И тут в голове возникла мысль: А какой смысл в этих собеседованиях? Just for fun? Обратился к Кириллу и Рахиму с этим вопросом, а мне вместо готовых ответов простая фраза в один голос: Иди и поспрашивай у Димы, на его примере и поймешь (ну прям в духе Хекслета: ответов не дали, поди и сам пойми, вот она дорога - тебе в ту сторону. Знакомо? =).

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

Несмотря на то, что свою первую строчку кода я написал ещё в школьные годы на мифишных подготовительных курсах (там был паскаль), и образование имею вполне себе профильное (бизнес-информатика), после универа жизнь как-то забросила в другое русло, и лет эдак шесть я вообще был в стороне от этой темы, занимаясь совершенно разными вещами, вроде участия в создании ютуб канала для одной кинокомпании (даже в офисе Гугла побывал!) или продажи услуг в World of Warcraft.

Однако, в какой-то момент наступило озарение и я решил, что хватит избегать своей сущности и пора вернуться в родную стихию. Начал копать в поисках каких-нибудь курсов и отзывов о них, в итоге наткнулся на тред на дваче (of all places), где анон очень позитивно отзывался о Хекслете. Цепануло упоминание о том, что сами создатели напрямую общаются с аудиторией, отвечают на вопросы и вообще всячески помогают. Надо сказать, что про Хекслет я впервые услышал задолго до этих самых поисков: наткнулся как-то в своей ленте на видео у Кати Гавриловой, с которой учился на одном курсе, но в тот момент серьёзного значения не придал, и только открыв одно из видео с Кириллом осознал, что где-то этого достопочтенного господина я уже видел, благо память на лица хорошая, затем, копнув ютуб канал и найдя-таки то интервью, решил, что это судьба и в тот же день оформил подписку.

Кирилл провёл очередное публичное собеседование.

Привет. Когда-то я пообещал написать продолжение моей "Истории успеха", рассказать о том, как я устроился на работу после Хекслета и о начальном периоде работы. Постараюсь описать проблемы, с которыми столкнулся и одну необычную вещь, которая со мной приключилась. Надеюсь вам будет полезно и интересно.

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

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

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

Вы мучаетесь, потому что вам не отвечают на резюме? Вы знаете, что у вас есть необходимые для работы навыки, но вы не можете убедить компанию нанять вас?

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

В этом посте я расскажу о:

• Самой важной части вашего резюме — первых абзацах.
• Почему начинать с технологий ошибочно.
• На чём делать акцент.