Хочу поделиться полезными приемами работы с PostgreSQL (другие СУБД имеют схожий функционал, но могут иметь иной синтаксис).

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

Данный материал будет полезен тем, кто полностью освоил базовые навыки SQL и желает учиться дальше. Советую выполнять и экспериментировать с примерами в pgAdmin'e, я сделал все SQL-запросы выполнимыми без разворачивания каких-либо дампов.

Поехали!

Так уж повелось, что программисты закрепляют удачные решения в виде шаблонов проектирования. По шаблонам существует множество литературы. Классикой безусловно считается книга Банды четырех «Design Patterns» by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides" и еще, пожалуй, «Patterns of Enterprise Application Architecture» by Martin Fowler. Лучшее из того, что я читал с примерами на PHP – это «PHP Objects, Patterns and Practice» by Matt Zandstra. Так уж получилось, что вся эта литература достаточно сложна для людей, которые только начали осваивать ООП. Поэтому у меня появилась идея изложить некоторые паттерны, которые я считаю наиболее полезными, в сильно упрощенном виде. Другими словами, эта статья – моя первая попытка интерпретировать шаблоны проектирования в KISS стиле.
Сегодня речь пойдет о том, какие проблемы могут возникнуть с инициализацией объектов в ООП приложении и о том, как можно использовать некоторые популярные шаблоны проектирования для решения этих проблем.

Этот перевод — для новичков, делающих первые шаги в JavaScript, или даже в программировании вообще.


JavaScript — мощный объектно-ориентированный (ООП) язык. Но, в отличие от многих других языков, он использует ООП-модель на основе прототипов, что делает его синтаксис непривычным для многих разработчиков. Кроме того, JavaScript работает с функциями как с объектами первого класса, что может путать программистов, не знакомых с этими концепциями. Можно обойти их, применяя производный язык вроде TypeScript, имеющий знакомый синтаксис и предлагающий дополнительные возможности. Но такие языки всё-равно компилируются в чистый JavaScript, и простое знание об этом не поможет вам понять, как они работают на самом деле, а также когда целесообразно их применять.

О чём мы поговорим в этой статье:

• Пространство имён.
• Объекты.
• Объектные литералы.
• Функции-конструкторы.
• Наследование.

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

Но на этом история не заканчивается. Распределение простых чисел выглядит случайным, с неравномерными разрывами и скоплениями, которые выглядят довольно хаотично. Если и существует какая-то схема, то она непостижима. На самом деле, простые числа выглядят достаточно случайными, чтобы можно было сыграть с ними в кости. Создайте список последовательных простых чисел (допустим, начав с 11, 13, 17, 19,... ) и разделите их по модулю 7. Другими словами, разделите каждое простое число на 7 и сохраните только остаток. Результатом будет последовательность целых чисел из множества {1, 2, 3, 4, 5, 6}, которая выглядит почти как результат нескольких бросков правильной кости.

$$

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

Тема заезженная до дыр, не спорю… Вероятно, для опытных разработчиков моя статья будет мало, чем полезна. Я бы рекомендовал её к прочтению тем, кто только начал осознавать, что его коду чего-то не хватает, и что он созрел для вникания в это далёкое понятие – «паттерны». По себе помню, что довольно долгое время я путался в шаблонах, иногда даже не понимая, чем один отличается от другого. Именно этот факт стал основой для моей статьи. Примеры в ней не будут реальными. Они будут абстрактными и максимально простыми. Однако я постараюсь все примеры держать в едином контексте, чтобы можно было наглядно видеть отличия их использования в одной и той же ситуации. Я не буду нагружать классы лишним функционалом, чтобы можно было понять, какая именно часть кода имеет непосредственное отношение к шаблону. Главными героями примеров станут Factory (фабрика) и Product (продукт, производимый этой фабрикой). Возьмём это отношение за отправную точку. Возможно, в некоторых примерах это будет не очень уместно, но зато очень наглядно…

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

Не так давно у нас в компании проводили обучение для потенциальных будущих менеджеров и в том числе пригласили одного из топ-менеджеров «на поговорить».

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

Но потом разговор пришел к теме, над которой я тех пор размышляю: burnout/выгорание. По моим воспоминаниям, еще лет десять назад об этом или не говорили вообще, считая какой-то вымышленной проблемой (как, к сожалению, многие по-прежнему относятся к ментальным заболеваниям, путая депрессию и плохое настроение) или говорили об этом как говорят о чем-то постыдном типа алкоголизма с подтекстом «со мной такое не может случиться».

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

Предисловие

Сервис-воркеры (Service Workers, да простят меня читатели) сегодня являются полезным дополнением к основной функциональности сайта: тут и работа в оффлайне, и фоновая синхронизация данных, и модные пуш-уведомления.

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

Недавно довелось прочитать статью под названием «Мы уволили самого талантливого сотрудника. Это лучшее решение, которое мы когда-либо делали». [Очень популярная статья, которая получила массу положительных оценок на Medium — прим. пер.]

Давайте присядем, вы и я. Нужно поговорить. Если вы не читали статью по ссылке, то уделите 10–15 минут и прочитайте, впитайте её целиком.

Готовы? Отлично. Теперь разберём этот текст, потому что он значит гораздо больше, чем там написано. Если вы прочитали статью, то понимаете, что автор описывает проблемного сотрудника под вымышленным именем «Рик». Рик — это местный гений с огромным количеством знаний в предметной области, он входит в состав ключевых разработчиков продукта.

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

Честно предупреждаю: воспринимайте этот текст с определённой долей скептицизма. Я лишь недавно начал знакомство с внутренностями PHP, но хотел бы рассказать вам о том, что творится за кулисами бага #75237.

В резко-критическом отзыве на весенний трейлер фильма «Салют-7» я совершенно искренне написал, что хотел бы ошибиться в своих ожиданиях и чтобы кино в итоге получилось хорошим. Увы, досмотреть фильм я смог только потому, что уже в первой его половине переключил восприятие с режима «историческое кино» на «ненаучная фантастика». Вкусы — дело личное, кому-то картина возможно и понравится. В любом случае, разнообразные ошибки и неточности — отличный повод поговорить о том, что на самом деле происходило в истории, и как работала показанная на экране техника. И под занавес хочется рассказать, каким бы на мой взгляд был идеальный фильм по этим событиям.


Кадр из фильма

До релиза Firefox Quantum остаётся всё меньше времени. Он принесёт множество улучшений в производительности, в том числе сверхбыстрый движок CSS, который мы позаимствовали у Servo.

Но есть ещё одна большая часть технологии Servo, которая пока не вошла в состав Firefox Quantum, но скоро войдёт. Это WebRender, часть проекта Quantum Render.



WebRender известен своей исключительной скоростью. Но главная задача — не ускорить рендеринг, а сделать его более плавным.

При разработке WebRender мы поставили задачу, чтобы все приложения работали на 60 кадрах в секунду (FPS) или лучше, независимо от размера дисплея или от размера анимации. И это сработало. Страницы, которые пыхтят на 15 FPS в Chrome или нынешнем Firefox, летают на 60 FPS при запуске WebRender.

Как WebRender делает это? Он фундаментальным образом меняет принцип работы движка рендеринга, делая его более похожим на движок 3D-игры.

Представляю вам мой довольно вольный перевод статьи 5 Easy Steps to Understanding JSON Web Tokens (JWT). В этой статье будет рассказано о том, что из себя представляют JSON Web Tokens (JWT) и с чем их едят. То есть какую роль они играют в проверке подлинности пользователя и обеспечении безопасности данных приложения.

Тема полезных приёмов работы в терминале Linux неисчерпаема. Казалось бы — всё устроено очень просто: приглашение оболочки, да введённые с клавиатуры команды. Однако, в этой простоте кроется бездна неочевидных, но полезных возможностей. Именно поэтому мы регулярно публикуем материалы, посвящённые особенностям работы в командной строке Linux. В частности, сегодня это будет перевод статьи, автор которой увлечён экономией времени через повышение продуктивности труда.



Если вас интересует работа в командной строке Linux — вот некоторые из наших материалов на эту тему:

• [ +114 ] Самые полезные приёмы работы в командной строке Linux
  
• [ +70 ] 10 приёмов работы в терминале Linux, о которых мало кто знает
  
• [+65 ] Удивительно полезный инструмент: lsof
  
• [ +32 ] Linux: перенаправление
  
• [ +29 ] PDF-версия статей про Bash-скрипты
  

Вышел релиз PostgreSQL 10. Мы долго ждали появления новых фич. Мои коллеги ещё весной тестировали новую версию и отправляли баг-репорты: раз, два. А я был очень рад обновлению и подготовил перевод Release Notes на русский язык. Давайте обсуждать.

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

Итак, что же нового в этой версии PostgreSQL?

Во-первых, изменилось само версионирование. До "десятки" мы наблюдали множество минорных версий 9.x, которые выходили примерно раз в год и при этом вносили серьезные, далеко не минорные изменения. Поэтому с версии 10 было принято решение сделать нумерацию 10, 11, 12 и т.д. Кстати, MySQL, похоже пошел по тому же пути, прыгнул с 5.7 на 8.0

Ладно, это всё мелочи, перейдем к существу вопроса

Рут – это мифическое существо в экосистеме Linux. Он может всё: зайти в любой каталог, удалить любой файл, завершить любой процесс, открыть любой порт. В общем это суперчеловек, чрезвычайно могущественный и очень полезный. Но задумывались ли вы когда-нибудь, какую цену мы платим руту? Не думали же вы, что он работает за просто так.

Вы знаете команду df? Она показывает все подключенные сейчас диски и статистику по ним: сколько место занято, сколько свободно. Например:

$ df -m
Filesystem     1M-blocks   Used Available Use% Mounted on
udev                 224      1       224   1% /dev
tmpfs                 48      1        47   2% /run
/dev/dm-0           9204   7421      1294  86% /

Вы когда-нибудь замечали, что для локальных дисков сумма Used и Available чаще всего меньше общего размера диска? Ненамного, но меньше.

<update>

Время несётся стремительным домкратом. Эта статья в значительной степени устарела, хоть конструктивные моменты типа «изучайте смежные области» едва ли когда утратят актуальность. Кадровый голод ощущается всё более явно и вносит больше конструктива в процесс найма начинающих разработчиков. Баланс смещается в сторону хороших знаний языка и инструментов от готовности к написанию кода «как-нибудь» но с первого дня.

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

</update>

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

При написании этой статьи:

• в той или иной мере был контакт с 20+ работодателями
• выполнено 12 тестовых заданий
• пройдено 8 собеседований с техническими специалистами
• получил моральные травмы средней степени тяжести один начинающий PHP-разработчик

Итак, по следам трех публикаций от 30.09, 03.10 и 04.10 я решил рискнуть и попытаться подвести итог. Конечно, не хватает комментариев от крупных компаний с их частными школами, программами стажировок и прочего, комментариев администрации ВУЗов (хотя часть я попробую осветить) и некоторых других. Из тех, которые я учитывал (самое сложное было просмотреть эту кучу комментариев) — 1, 2, 3, 4. Поэтому всех авторов призываю прокомментировать, верно ли я передал их позицию: @aleshqqa1337, PavelMSTU, Axelus, MooNDeaR, Varim, ternaus, san-smith.

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

Недавно у меня появилась возможность выполнить отладку буфера обмена в Windows, и я решил, что хорошо бы поделиться информацией, которую удалось узнать. Буфер обмена — это тот компонент Windows, который многие из нас используют десятки (сотни?) раз в день, особо не размышляя об этом. Прежде чем взяться за это дело, я даже никогда не задумывался, как всё устроено. Как выяснилось, там столько интересного, что вы даже не можете себе представить. Сначала опишу, как приложения хранят разные типы данных в буфере обмена и как извлекают их оттуда, а затем — как приложения могут «прицепиться» к буферу и отслеживать изменения в нём. В обоих случае вы увидите отладочные записи, которые показывают, как получить доступ к данным из отладчика.

Начнём с обсуждения форматов буфера обмена. Такие форматы используются для описания, какие типы данные можно поместить в буфер. Там есть некоторое количество предопределённых стандартных форматов, которые может использовать приложение, вроде битового массива, текста ANSI, текста в Юникоде и TIFF. Windows также позволяет приложению установить собственный формат. Например, текстовый процессор может зарегистрировать формат, включающий в себя текст, форматирование и картинки. Конечно, это ведёт к определённой проблеме: что произойдёт, если вы скопируете данные из текстового редактора и вставите их в «Блокнот», который не понимает всего этого форматирования и не отображает картинки?