Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

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

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

Отработав много лет в компаниях, занимающихся разработкой программного обеспечения на заказ, невольно начинаешь задумываться — а как всё-таки выглядит вся эта суета с другой стороны, со стороны заказчика? Грешным делом начинает казаться, что там всё просто и понятно, все люди сведущи и профессиональны, решения принимаются осмысленно и обоснованно, да и вообще, жизнь кипит, а не как в этом нашем айтишном болоте…

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

В прошлые разы мы рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа, и два метода: хеш-индекс и B-дерево. В этой части займемся индексами GiST.

GiST

GiST — сокращение от «generalized search tree». Это сбалансированное дерево поиска, точно так же, как и рассмотренный ранее b-tree.

В чем же разница? Индекс b-tree жестко привязан к семантике сравнения: поддержка операторов «больше», «меньше», «равно» — это все, на что он способен (зато способен очень хорошо!). Но в современных базах хранятся и такие типы данных, для которых эти операторы просто не имеют смысла: геоданные, текстовые документы, картинки…

Тут на помощь и приходит индексный метод GiST. Он позволяет задать принцип распределения данных произвольного типа по сбалансированному дереву, и метод использования этого представления для доступа по некоторому оператору. Например, в GiST-индекс можно «уложить» R-дерево для пространственных данных с поддержкой операторов взаимного расположения (находится слева, справа; содержит и т. п.), или RD-дерево для множеств с поддержкой операторов пересечения или вхождения.

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

Как все начиналось

Дело было вечером, делать было нечего… Точнее, я просто хотел загрузить аудиокнигу перед парами и тут меня ждал сюрприз. Кэш в кейт мобайле отключили. Как так? Что делать? Конечно же писать свое приложение с кэшем и аудиозаписями. Но для начала нужно понять, как вк превращает ссылки вида audio%user_id%_%track_id% в прямые ссылки на mp3. Что из этого вышло приложения я не написал и как скачать определенный плейлист можно прочитать под катом.

Хочу поделиться полезными приемами работы с 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

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