Robots.txt указывает веб-краулерам мира, какие файлы можно или нельзя скачивать с сервера. Он как первый сторож в интернете — не блокирует запросы, а просит не делать их. Интересно, что файлы robots.txt проявляют предположения веб-мастеров, как автоматизированным процессам следует работать с сайтом. Хотя бот легко может их игнорировать, но они указывают идеализированное поведение, как следует действовать краулеру.

По существу, это довольно важные файлы. Так что я решил скачать файл robots.txt с каждого из 1 миллиона самых посещаемых сайтов на планете и посмотреть, какие шаблоны удастся обнаружить.

Я взял список 1 млн крупнейших сайтов от Alexa и написал маленькую программу для скачивания файла robots.txt с каждого домена. После скачивания всех данных я пропустил каждый файл через питоновский пакет urllib.robotparser и начал изучать результаты.


^{Найдено в yangteacher.ru/robots.txt}

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

На написание статьи меня подтолкнули простые причины: идет война за сердца и умы разработчиков, и многие уважаемые софтверные гиганты считают своей обязанностью облегчить участь девелопера (что хорошо, кстати). При этом не стесняясь сломать ему мозг и нервную систему (а вот это не очень). Так сказать, во имя счастья будущих поколений. Может быть, я ошибаюсь, но хочу поделиться с вами информацией об инструменте, который достаточно давно открыл для себя и с тех пор не ем кактусы, как те мыши: Mithril (MithrilJS).

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

Но у меня нет сторонних проектов. У меня нет аккаунта на GitHub. У меня нет open-source проектов, которые я строгаю по вечерам. У меня ровно ноль пулл-реквестов в любой из последних модных проектов, в которых участвуют все крутые кодеры. Я не вожусь с упражнениями в Haskel. И я ненавижу хакатоны.

И когда я сказал, что не могу показать им сторонних проектов — для них это звучало так, что я не лучший. Я не увлечённый разработчик. Я не уделяю достаточно времени тому, чтобы поддерживать на высоком уровне своё образование и навыки. Программирование — это «просто работа».

В свободной продаже (как в бумаге, так и электронные версии), появилась новая научно-фантастическая книга популярного американского писателя Нила Стивенсона «Семиевие». Переводом и издательством книги занимались ребята из FanZon. Книга, как и сам автор, обласкана множественными восторженными отзывами критиков и прочими литературными премиями, которые даются современным фантастам.

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

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

Вчера я разговаривал с другом, который ищет разработчика на открытую вакансию. Он выразил некоторое разочарование, которое я тоже испытываю в последнее время:

У меня проблемы с поиском фронтенд-разработчика, в основном, по WP, Foundation, CSS, JS, на низкоуровневую позицию. Не могу понять, в чём дело. Ни у кого из кандидатов нет «базовых знаний» ничего из перечисленного. Но они могут делать сайты на React или других JS-фреймворках, или на базе WP-шаблонов. Но если я говорю, что нужно сделать простые изменения в CSS, смотрят пустыми глазами… Или какую-нибудь мелочь на чистом JS, ничего.

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

Конечно, есть ограничения на то, сколько можно усвоить за 12 недель обучения. Но огромная часть проблемы в том, что наша индустрия восхищается новым, одержима самыми последними и прекрасными SPA-фреймворками, в то же время обесценив CSS и «старые» имплементации.

Состоялся релиз PHP фреймворка Yii версии 2.0.13. В него вошли более 90 улучшений и исправлений.

Обратите внимание, что в релиз попали изменения, которые могут повлиять на существующие приложения. Они описаны в UPGRADE.md.

Огромное спасибо сообществу Yii за поддержку и пулл-реквесты!

За процессом разработки можно следить поставив звёздочку на GitHub. Также подписывайтесь
на наш Twitter и Facebook.

Так как мы работаем над Yii 2.1, убедитесь что версия фреймворка в composer.json прописана верно (~2.0.13) и вы не обновитесь на 2.1 случайно когда он релизнется.

Ниже мы рассмотрим самые интересные улучшения и исправления релиза. Полный список можно найти в CHANGELOG.

Недавно мне позвонили и попросили помочь разобраться с очень странными симптомами на сайте. А симптомы выглядели вот так. Cовершенно разные клиенты звонили и рассказывали, что они на сайте попадают в личные кабинеты других случайных клиентов. Логинятся под собой. Входят в свой аккаунт, а потом бац – и уже в аккаунте другого клиента. Правда они не догадывались, что кто-то другой так же мог оказаться в их личном кабинете.

Давайте я расскажу «историю неуспеха», чтобы другие на эти грабли не наступали.

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

Сначала эта задача показалась мне невыполнимой, но я нашел html2canvas.

Данный текст является вольным переводом вот этой главы замечательной книги «High Performance Browser Networking» авторства Ильи Григорика. Перевод выполнялся в рамках написания курсовой работы, потому очень вольный, но тем не менее будет полезен тем, кто слабо представляет что такое TLS, и с чем его едят.

Общие сведения о TLS

Протокол TLS (transport layer security) основан на протоколе SSL (Secure Sockets Layer), изначально разработанном в Netscape для повышения безопасности электронной коммерции в Интернете. Протокол SSL был реализован на application-уровне, непосредственно над TCP (Transmission Control Protocol), что позволяет более высокоуровневым протоколам (таким как HTTP или протоколу электронной почты) работать без изменений. Если SSL сконфигурирован корректно, то сторонний наблюдатель может узнать лишь параметры соединения (например, тип используемого шифрования), а также частоту пересылки и примерное количество данных, но не может читать и изменять их.

Каждый разработчик ПО умеет программировать, но не каждый программист может разрабатывать ПО

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

Возможно, кому-то больше нравится говорить не «разработчик», а инженер-программист, ведь инженер — это звучит гордо! Или нет? К счастью, эта статья не о терминах. Если мой термин вам не нравится — подставьте свой: «автор ПО», «мастер ПО»… и даже «творец приложений»!

Говоря «разработчик ПО», я имею в виду человека, для которого написание качественного ПО — профессия. Человека, который использует в своей работе научные подходы и статистику и считает свое занятие чем-то большим, чем просто зарабатывание денег.

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

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

Мне нравится такая аналогия: каждый может ради собственного развлечения петь в ду́ше, но вы же не ставите треки с записями этого пения на вечеринке — вы обращаетесь к произведениям профессиональных музыкантов.

Хотите еще аналогий? Пожалуйста:

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

Главная задача этого текста — донести, что создание простых программ серьезно отличается от разработки ПО.

Переведено в Alconost

У нас в Skyeng работают весьма талантливые люди. Вот, например, бэкенд-разработчик Words Сергей Жук написал книгу про событийно-ориентированный PHP на ReactPHP, основанную на публикациях его блога. Книга англоязычная, мы решили перевести одну самодостаточную главу в надежде, что кому-то она сможет пригодиться. Ну и дать скидочную ссылку на всю работу.

Мы уже познакомились с механизмом индексирования PostgreSQL и с интерфейсом методов доступа, и рассмотрели хеш-индексы, B-деревья, индексы GiST и SP-GiST. А в этой части займемся индексом GIN.

GIN

— Джин?.. Джин — это, кажется, такой американский спиртной напиток?..
— Не напиток я, о пытливый отрок! — снова вспылил старичок, снова спохватился и снова взял себя в руки. — Не напиток я, а могущественный и неустрашимый дух, и нет в мире такого волшебства, которое было бы мне не по силам.

Лазарь Лагин, «Старик Хоттабыч».

Gin stands for Generalized Inverted Index and should be considered as a genie, not a drink.

README

Общая идея

GIN расшифровывается как Generalized Inverted Index — это так называемый обратный индекс. Он работает с типами данных, значения которых не являются атомарными, а состоят из элементов. При этом индексируются не сами значения, а отдельные элементы; каждый элемент ссылается на те значения, в которых он встречается.

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

13 октября мы провели вторую конференцию сообщества Uptime. В этот раз дата проведения выпала на пятницу 13-е, поэтому основная тема — аварии, и как с ними справляться. Это первый из серии постов про доклады с прошедшей конференции.

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

Свежая подборка со ссылками на новости и материалы. В выпуске: PHP 7.2.0 RC5 и другие релизы, предложения из PHP Internals, порция полезных инструментов, и многое другое.
Приятного чтения!

В свободное и не свободное время[1] я развиваю несколько своих проектов на github, а также, по мере сил, участвую в жизни интересных для меня, как программиста, проектах.

Недавно один из коллег попросил консультацию: как выложить разработанную им библиотеку на github. Библиотека никак не связана с бизнес-логикой приложения компании, по сути это адаптер к некоему API, реализующему определённый стандарт. Помогая ему, я понял что вещи, интуитивно понятные и давно очевидные для меня, в этой области, совершенно неизвестны человеку делающему это впервые и далёкому от Open Source.

Я провел небольшое исследование и обнаружил что большинство публикаций по этой теме на habrahabr освещают тему участия (contributing), либо просто мотивируют каким-нибудь образом примкнуть к Open Source, но не дают исчерпывающей инструкции как правильно оформить свой проект. В целом в рунете, если верить Яндекс, тема освещена со стороны мотивации, этикета контрибуции и основ пользования github. Но не с точки зрения конкретных шагов, которые следует предпринять.

Так что из себя представляет стильный, модный, молодёжный Open Source проект в 201* году?

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

Тульпы. Сообщество со странными идеями и целями, объединённое мистической терминологией. Десятки людей, практикующих форсинг, гипноз, изменяющих своё сознание, медитирующих, пытающихся справиться со своими заболеваниями. Все они собрались вместе из-за общей цели: создать то, что Википедия называет «воображаемым другом». Но что такое тульпы на самом деле?

Зачастую, одно из первых архитектурных решений, принятых в начале разработки вашего сайта — будет использование email + password для авторизации пользователя. Эта связка прочно засела в наши головы, и мы уже на задумываемся, зачем мы заставляем людей придумывать пароль. Мы привыкли так делать.

Но давайте подумаем, возможно, вашим пользователям не нужны пароли.

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

Но как-же тогда избавиться от пароля? На этот вопрос, я и попробую ответить в статье.

Все началось с того, что мне нужно было разработать поиск пациентов для одной внутренней медицинской системы. Логика работы была в том, что если мы не нашли человека в системе, то его нужно создать (а дубли пациентов плодить нельзя). В связи с этим одной из подзадач стала реализация поиска людей с учетом опечаток в их именах. Ну а поскольку я люблю PostgreSQL (а когда в руках у тебя молоток, то все похоже на гвозди), не сложно угадать, на чем я решил реализовать поиск с опечатками…

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

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

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

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

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

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