Одно из наиболее важных решений, которые принимает разработчик, заключается в том, какую базу данных использовать. В течение многих лет опции были ограничены различными вариантами реляционных баз данных, которые поддерживали язык структурированных запросов (SQL). К ним относятся MS SQL Server, Oracle, MySQL, PostgreSQL, DB2 и многие другие.

За последние 15 лет на рынке появилось много новых баз данных в рамках подхода No-SQL. К ним относятся хранилища ключей-значений, такие как Redis и Amazon DynamoDB, широкие колоночные базы, такие как Cassandra и HBase, хранилища документов, такие как MongoDB и Couchbase, а также графовые базы данных и поисковые системы, такие как Elasticsearch и Solr.

В этой статье мы попробуем разобраться в SQL и NoSQL, не влезая в их функционал.
Кроме того, мы немного повеселимся в процессе.

Как я хотела прикинуть, что дешевле – уволить выгоревшего сотрудника, «вылечить» или вовсе стараться не допускать выгорания, и что из этого получилось.

Сейчас небольшое вступление, откуда родилась эта тема.

Я почти что разучилась писать. Сначала нет времени; потом кажется, что все, о чем ты можешь/хочешь написать – это очевидно, а потом ты слышишь историю от коллеги из одной известной компании, который рассказывает, что в пятницу в 10 часов вечера их генеральный на полном серьезе уточняет: «Я тут побывал в департаменте разработки 5 минут назад. Почему еще только 10 вечера, а в офисе уже никого нет?»

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

Друзья! Мы продолжаем серию публикаций «без купюр» о проектных процессах, IT-технологиях и о том, как работать эффективно. Сегодня поговорим об очень наболевшей теме, вызывающей изжогу в головном мозге — выборе технологий, языков программирования, роли архитекторов, аналитиков, тимлидов и экстрасенсов для решения эпической задачи: запустить программное решение, если возможно, в разумный срок. И отдельно остановимся, ну чтобы совсем не заскучать, на анализе корреляции размеров частей тела одной части коллектива с производительностью работы мозга другой. Наливайте кофе и поехали!

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

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

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

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

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

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

5 сентября в Москве состоялся Круглый стол «Архитектор ИТ проекта» в ВШЭ. Организатор круглого стола, Максим Смирнов, ведет блог про архитектуру и канал на Facebook.

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

На круглом столе было представлено 4 доклада по 15-20 минут, после чего были вопросы из аудитории и обсуждение.

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

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

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

Но с такими возможностями часто приходит полное отсутствие уважения к участникам проекта других профессий. Это отсутствие уважения может оказаться настолько глубоким, что порождает в уме разработчика твёрдую уверенность, что он не только самый ценный участник программного проекта, но и необходим компании в целом. К сожалению, хотя лишь малое число разработчиков способны накапливать что-либо напоминающее богатство, многие ведут себя так, словно они следующие Марк Цукерберг, Билл Гейтс или Стив Джобс; хотя это очень далеко от истины. Это приводит к личностным проблемам, которые так же увлекательно наблюдать со стороны, как страшно созерцать в себе.

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

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

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



Материал, перевод которого мы сегодня публикуем, посвящён основам SOLID и предназначен для начинающих разработчиков.

Привет, Хаброжители! Эта книга подойдет для любого разработчика, который хочет разобраться в потоковой обработке. Понимание распределенного программирования поможет лучше изучить Kafka и Kafka Streams. Было бы неплохо знать и сам фреймворк Kafka, но это не обязательно: я расскажу вам все, что нужно. Опытные разработчики Kafka, как и новички, благодаря этой книге освоят создание интересных приложений для потоковой обработки с помощью библиотеки Kafka Streams. Java-разработчики среднего и высокого уровня, уже привычные к таким понятиям, как сериализация, научатся применять свои навыки для создания приложений Kafka Streams. Исходный код книги написан на Java 8 и существенно использует синтаксис лямбда-выражений Java 8, так что умение работать с лямбда-функциями (даже на другом языке программирования) вам пригодится.