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

Что же, в последнее время, в своей работе я во всех проектах задействую lodash (кому-то может больше нравиться underscore). Для меня это, фактически, — стандарт. В очередной раз пробегая глазами API, я решил составить для себя шпаргалку в виде: «название функции» — «краткое описание». Так удобно освежать API в памяти. Может кому пригодится.

Это циничная, клиническая коллекция того, чему я научился за 30 лет работы в разработке программного обеспечения. Повторюсь, некоторые вещи весьма циничны, а остальное — результат долгих наблюдений на разных местах работы.

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

Мы выяснили, что самой популярной формой допобразования — после самообразования с помощью книг, видео и блогов — являются курсы: 64% специалистов практикуют такой формат. Во второй части исследования мы разберёмся с существующими на отечественном рынке школами допобразования, узнаем самые популярные, что конкретно они дают своим выпускникам, построим их рейтинг.

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

У каждого кандидата в конце собеседованию рекрутер обычно спрашивает, есть ли вопросы. Часто люди теряются и не находят, что спросить. И лишь по прошествии некоторого времени (часто, когда человек уже работает в компании) сами собой всплывают вопросы, о которых нужно было поинтересоваться заранее, а не брать кота в мешке и удивляться «Как я сюда попал? Куда я смотрел? Почему я об этом не подумал?». Это так называемый «эффект лестницы». Я подготовил шпаргалку, что ты, %habrauser%, не растерялся.

Общее

1. Рабочий график и можно ли его двигать?
Я люблю поспать. Но на моей прошлой работе «рабочее утро» начиналось в 7:30. Мало того, что я довольно часто не мог прийти к этому времени, я еще пол дня занимался тем, что пытался привести себя в рабочую форму. Где то до 10:00. С 10:30 до 11:30 я усердно работал. Потом был обед. А потом мне хотелось спать, а не работать, т.к. я не высыпался еще с утра. Надо ли говорить, что вместо 8 часов, на которые меня нанял работодатель, я работал в «потоке» только часа 3-4. Так что для себя нужно решить вопрос – когда я наиболее трудоспособен? И обговорить рабочий график с руководством. И еще один нюанс. Попробуйте закрепить обговоренный график в трудовом договоре или контракте (далее ТД), если работодатель идет на персональный рабочий график для Вас. Никаких устных договоренностей. Иначе Вам начнут крутить руки уже в процессе работы (как это было со мной).

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

Недавно меня спросили, чем разработка на C# отличается от разработки на C++. В результате родилась идея объяснить значение тех или иных ИТ терминов на примере процесса выращивания картошки.

Не так давно промелькнула ссылка на достаточно свежее (осень 2011) англоязычное голосование со скромным названием "самая впечатляющая книга, которую должен прочесть каждый разработчик программного обеспечения" и описанием:

Если бы вы могли вернуться в прошлое, к самому началу своей карьеры разработчика и сказать самому себе: «прочитай именно эту книгу», в самой начале своей карьеры разработчика, какую бы книгу вы рекомендовали?

Тема перевода зарубежной профессиональной IT-литературы стоит достаточно остро, многие любят читать книги в оригинале по различным причинам, таким так время выхода русского перевода с запозданием на годы, недостаточный профессионализм переводчика и соответствующая потеря тонкостей и авторского стиля и т.д.

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.

Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно.
Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.

Я работаю в сфере IT чуть более 1 года как Test Automation Engineer.

Мое базовое образование никак не способствовало этому, поскольку в моем дипломе написано “Логистик-Экономист”. Тернистный путь в IT я начала с бесплатных курсов при одной крупной компании в моем городе, после них поработала в той же компании на 2х проектах, после чего решила сменить место работы.