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

- Джордж Р.Р. Мартин.

Проектирование и работа с REST-сервисами стали повседневными задачами для многих аналитиков. Однако мы часто встречаемся на работе с различными или даже противоречащими друг другу трактовками таких понятий, как REST, RESTful-сервис, RESTAPI.

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

Выясним, почему существует терминологическая путаница вокруг REST и как нам научиться лучше понимать коллег.

Поговорим о том, как связаны HTTP и REST. А также почему REST противопоставляют SOAP.

Наткнулся на любопытный материал, в котором автор систематизировал и записал свой опыт инженера-программиста в 20 тезисов. Я работаю в коммерческой разработке ПО больше 25 лет, и этот текст отозвался во мне практически каждой буквой — большинство советов я тоже регулярно практикую, не облекая их в формат ёмких афоризмов. В общем, решил сделать перевод.

Особенно отзываются пункты «стройте компактные системы» и «лучший код — это отсутствие кода». Последний совет я превращаю в цитату из какого-то второсортного фильма про самураев: «Лучшая победа — та, которую ты одержал, не доставая меч из ножен» (думаю, сослуживцы за моей спиной уже закатывают глаза). И, конечно, бесконечные разговоры про легендарных 10x-программистов постоянно хочется прервать советом не связываться с 0,1x-программистами (которые реально существуют, в отличие от 10x).

Моя прошлая статья о поиске самозванцев среди программистов оказалась наиболее успешной по количеству положительных оценок за всю мою историю публикаций, и на втором месте по количеству просмотров (больше читали только "текстового Бэдкомедиана" на Гиктаймсе). Немало было и отрицательных оценок, дорогими читателями было предъявлена масса претензий и задано множество возмущенных вопросов; не забывали одноременно ушатать карму, чтобы я не мог на них ответить в коментах под собственной статьей. А что приятно удивило, большинство действительно развернутых и качественных комментариев было в мою поддержку (или плюс-минус нейтральными) - что мотивирует к продолжению данной тематики.

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

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

Два с половиной года назад я перешел из отрасли автоматизации промышленного оборудования, в которой я проработал почти 25 лет, в сферу банковского IT, разработчиком Java, и достиг (по оценке моего лида) уровня middle ++.

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

Если данная тема заинтересует хаброжителей - я могу написать подробную историю, почему и как я это сделал, пока ограничусь сухой выжимкой (исключив негативные моменты, мои личные переживания и прочую лирику).

На глаза попалась статья о приеме разработчиков на работу. Мы сейчас тоже ищем разработчиков, поэтому тема откликнулась. Автор статьи провел 20 собеседований и делится опытом, попутно давая советы соискателям. Мы, конечно же, провели гораздо больше собеседований и понимаем, что в этом деле не всё так однозначно, как пишет программист из США. И хотя статья достаточно спорная, я всё же решил поделиться и узнать, а как она вам?

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

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

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

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

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

Первый закон Паркинсона: работа заполняет время, отпущенное на неё.

Не правда ли, формулировка отдаёт какой-то безнадёгой? Старайся, планируй, работай над эффективностью, не отвлекайся, будь осознанным – толку ноль. Всё равно весь день просидишь. Меня такое положение дел не устраивало, и я, вдохновлённый энтузиазмом, кинулся ломать закон Паркинсона.

Хотел доказать самому себе, что могу управлять структурой и объемом работы так, чтобы она не занимала всё моё время. Что вышло, и к чему я в итоге пришёл – за разворотом.

<!DOCTYPE html>
<html lang="en" class="no-js">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width">

  <title>Unique page title - My Site</title>

  <script type="module">
    document.documentElement.classList.remove('no-js');
    document.documentElement.classList.add('js');
  </script>

  <link rel="stylesheet" href="/assets/css/styles.css">
  <link rel="stylesheet" href="/assets/css/print.css" media="print">

  <meta name="description" content="Page description">
  <meta property="og:title" content="Unique page title - My Site">
  <meta property="og:description" content="Page description">
  <meta property="og:image" content="https://www.mywebsite.com/image.jpg">
  <meta property="og:image:alt" content="Image description">
  <meta property="og:locale" content="en_GB">
  <meta property="og:type" content="website">
  <meta name="twitter:card" content="summary_large_image">
  <meta property="og:url" content="https://www.mywebsite.com/page">
  <link rel="canonical" href="https://www.mywebsite.com/page">

  <link rel="icon" href="/favicon.ico">
  <link rel="icon" href="/favicon.svg" type="image/svg+xml">
  <link rel="apple-touch-icon" href="/apple-touch-icon.png">
  <link rel="manifest" href="/my.webmanifest">
  <meta name="theme-color" content="#FF00FF">
</head>

<body>
  <!-- Content -->
  <script src="/assets/js/xy-polyfill.js" nomodule></script>
  <script src="/assets/js/script.js" type="module"></script>
</body>
</html>

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

Рассказываю, почему SQLite отлично подойдет вам в повседневной работе. И неважно, разработчик вы, аналитик, тестировщик, админ или продакт-менеджер.

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

После покупки цифрового фотоаппарата и рождения детей стало появляться большое количество фотографий, а учитывая, что жена с фотоаппаратом почти не расставалась и старалась запечатлеть все «важные» детские моменты, фотографий стало появляться ОЧЕНЬ много.

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

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