Продолжение: Рассказ о том, как не дать мне украсть номера кредиток и пароли у посетителей ваших сайтов

Представляем вам перевод статьи человека, который несколько лет воровал имена пользователей, пароли и номера кредитных карт с различных сайтов.

То, о чём я хочу рассказать, было на самом деле. Или, может быть, моя история лишь основана на реальных событиях. А возможно всё это — выдумка.

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

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

Я «просмотрел» 560 постов на Хабре и (предварительно) выделил для себя топ-10 самых полезных материалов про эмоциональное/профессиональное выгорание.

• Социальная архитектура: «Эмоциональное выгорание контрибьюторов Open Source проектов»
• Максим Дорофеев: «Принцип экономии мыслетоплива»
• Илья Якямсев: «Эффективность не работает»
• Сэм Альтман: «Продуктивность. Опыт лучших стартапов Y Combinator»
• Aaron Harris(YC): «Coping with Founder Depression»
• Jonathan Blow: «Techniques for dealing with lack of motivation, malaise, depression»
• «Проклятие второго месяца»
• «Как поколение Y превратилось в поколение выгоревших?»
• «Гори, гори ясно, пока не погасло», или Чем чревато эмоциональное выгорание ваших сотрудников
• «Я пережила выгорание, или Как остановить хомячка в колесе»

Моя гипотеза — если человеку действительно важен какой-то вопрос, он потратит на него более 100 часов (за несколько лет) и просмотрит более 100 (а может и 1000 публикаций). И чтобы «не делать работу дважды», было бы круто поделиться самыми ценными находками, это сократит время тому, кто пойдет следом.

Онтол — это персональный ранжированный список топ-10 самых полезных материалов на важную тему. Плюс лонглист (100+). Этот список можно постоянно дополнять в течение жизни и смены приоритетов, а так же «подглядывать» в списки других людей, находить полезные материалы и «братьев по оружию». (оставляйте почту, через неделю вышлю инвайт на закрытую бету.) Онтол про удаленную работу тут.

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

Под катом лонглист полезных материалов с Хабра про «выгорание» (ранжирован по хабрарейтингу). + Опрос в конце по следующим темам.

Мы привыкли, что стандартные коллекции в JDK сделаны достаточно хорошо и ведут себя интуитивно-понятно. Но так ли это на самом деле? Вчера Роман Елизаров elizarov опубликовал в твиттере новость о новом интересном косяке.

Держитесь покрепче: Set.removeAll(list) в определенных случаях может работать за O(N²). Как же так?

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

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

Будущее не за горами, поэтому приступать нужно уже сейчас.

Введение

В Haskell принято работать с эффектами как с функторами, объектами которых являются некоторые выражения, которые нам интересны в данный момент.

Когда мы видим тип выражения Maybe a, мы абстрагируемся от фактического существования некоторого a, сконцентрировав все внимание именно на этом a. Та же история с List a — множественные значения a; State s a — a, зависящая от некоторого текущего состояния; Either e a — a, которое может вернуть некоторую ошибку e.

В Serokell мы занимаемся не только коммерческими проектами, но стараемся изменить мир к лучшему. Например, работаем над улучшением главного инструмента всех хаскелистов – Glasgow Haskell Compiler (GHC). Мы сосредоточились на расширении системы типов под впечатлением от работы Ричарда Айзенберга "Зависимые типы в Haskell: теория и практика".

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

Перед вами обновляемый список самых замечательных «вкусностей» Юникода, а также пакетов и ресурсов

Юникод — это потрясающе! До его появления международная коммуникация была изнурительной: каждый определял свой отдельный расширенный набор символов в верхней половине ASCII (так называемые кодовые страницы). Это порождало конфликты. Просто подумайте, что немцам приходилось договариваться с корейцами, где чья кодовая страница. К счастью, появился Юникод и ввёл общий стандарт. Юникод 8.0 охватывает более 120 000 символов из более 129 письменностей. И современные, и древние, и до сих пор не расшифрованные. Юникод поддерживает текст слева направо и справа налево, наложение символов и включает самые разные культурные, политические, религиозные символы и эмодзи. Юникод потрясающе человечен, а его возможности сильно недооцениваются.

Часто в таблицах содержится большое количество логических полей, проиндексировать все из них нет возможности, да и эффективность такой индексации низка. Тем не менее, для работы с произвольными логическими выражениями в SQL пригоден механизм многомерной индексации о чем и пойдёт речь под катом.

HighLoad++ существует давно, и про работу с PostgreSQL мы говорим регулярно. Но у разработчиков все равно из месяца в месяц, из года в год возникают одни и те же проблемы. Когда в маленьких компаниях без DBA в штате случаются ошибки в работе с базами данных, в этом нет ничего удивительного. В крупных компаниях тоже нужны БД, и даже при отлаженных процессах все равно случаются ошибки, и базы падают. Неважно, какого размера компания — ошибки все равно бывают, БД периодически обваливаются, рушатся.



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


О спикере: Алексей Лесовский (lesovsky) начинал системным администратором Linux. От задач виртуализации и систем мониторинга постепенно пришел к PostgreSQL. Сейчас PostgreSQL DBA в Data Egret — консалтинговой компании, которая работает с большим количеством разных проектов и видит много примеров повторяющихся проблем. Это ссылка на презентацию доклада на HighLoad++ 2018.

В предыдущей статье мы рассказывали о том, что такое Attribute-Based Access Control и в чем его преимущества по сравнению с наиболее распространенным на сегодняшний день Role-Based Access Control. Пришло время рассмотреть ABAC более детально, через существующий стандарт под названием XACML.

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

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

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

Здесь мы рассмотрим несколько "улучшений", отклонённых из-за непонимания тонкостей спецификации языка, неочевидных угловых случаев и других причин. Поехали!

Скомпилируем простенькую программу выводящую "Hello World" и пройдемся по его структуре

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

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

А мы приступим к разбору самой структуры байт-кода для JVM

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



Под катом бытовая нейрофизиология для айтишников и традиционно ошибающийся здравый смысл.

Привет, Хабр! Представляю вашему вниманию перевод статьи «JavaScript Async/Await and Promises: Explained like you’re five years old» автора Jack Pordi.

Каждый, кто считает себя JavaScript-разработчиком, в какой-то момент должен был столкнуться с callback-функциями, промисами или, с недавних пор, с синтаксисом async/await. Если вы пробыли в игре достаточно долго, вы, вероятно, застали времена, когда вложенные callback-функции были единственным способом достижения асинхронности в JavaScript.

Когда я начал изучать и писать на JavaScript, уже существовало миллиард руководств и туториалов, объясняющих, как добиться асинхронности в JavaScript. Тем не менее, многие из них просто объясняли, как преобразовать callback-функции в промисы или промисы в async/await. Для многих этого, вероятно, более чем достаточно, чтобы они «поладили» с ними и начали использовать их в своем коде.

Однако если вы, как я, действительно хотите понять асинхронное программирование (а не только синтаксис JavaScript!), то, возможно, вы согласитесь со мной, что существует нехватка материалов, объясняющих асинхронное программирование фактически с нуля.

Ни для кого не секрет, что на данный момент Java — один из самых популярных языков программирования в мире. Дата официального выпуска Java — 23 мая 1995 года.

Эта статья посвящена основам основ: в ней изложены базовые особенности языка, которые придутся кстати начинающим “джавистам”, а опытные Java-разработчики смогут освежить свои знания.

* Статья подготовлена на основе доклада Евгения Фраймана — Java разработчика компании IntexSoft.
В статье присутствуют ссылки на внешние материалы.

Некролог: Митчелл Фейгенбаум, (1944‑2019), 4.66920160910299067185320382…

Статья из блога Стивена Вольфрама



Она называется постоянная Фейгенбаума и равняется примерно 4,6692016. И она с завидной периодичностью возникает в определённых видах математических – и физических – систем, способных демонстрировать хаотичное поведение.

Митчелл Фейгенбаум, ушедший от нас 30 июня в возрасте 74 лет, был открывшим её человеком – в 1975 году, и сделал это, занимаясь экспериментальной математикой на карманном калькуляторе.

Это открытие стало определяющим в теории хаоса. Но когда её обнаружили впервые, этот результат был неожиданным, причудливым, не связанным ни с чем из того, что изучалось ранее. Однако некоторым образом тот факт, что её открыл именно Митчелл Фейгенбаум – с которым я был знаком почти 40 лет – кажется подобающим.

Disclaimer: да, в понедельник мы опубликовали хабрапост с именно таким сравнением языков. Нет, мы не сошли с ума. Всё идёт по плану.

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

Эта хабрастатья — большое интервью с Виталием на следующие темы: 

• Преподавание и знакомство с JavaScript;
  
• Зачем выбирать Haskell;
  
• Место функциональных языков в жизни программиста;
  
• Чего хорошего в JavaScript и как он развивается;
  
• Что появится в языках программирования в ближайшие 10-15 лет;
  
• Какие языки программирования вызывают доверие и почему;
  
• В чем разница между научными конференциями и конференциями для разработчиков. Зачем преподавателю вообще на них ходить;
  
• Важно ли читать программисту, устаревают ли книги и какие из них must read.
  

Интервью ведут члены Программного комитета конференции HolyJS 2019 Moscow, Алексей Золотых и Артём Кобзарь. Если интервью вам недостаточно, то уже совсем скоро, на следующей HolyJS, Виталий расскажет и покажет на примерах, как связать JavaScript с теорией алгоритмов. 

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

В статье присутствуют Gif (трафик!) и контрастные картинки. У эпилептиков может случиться эпилептический припадок.

Мы потратили на создание этой игры несколько лет. От неё зависит будущее нашей семьи. Почему же она так ужасно выглядит?

Я уже 25 лет зарабатываю на жизнь написанием инди-игр. У нас с женой есть небольшой семейный бизнес. Мы создаём низкобюджетные ролевые игры в ретро-стиле с отличным сюжетом, дизайном и геймплеем.

Но все они выглядят как куча навоза.

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

Благодаря этой репутации мы провели на Kickstarter успешную кампанию по сбору средств на Queen's Wish: The Conqueror — потрясающую RPG, которая тоже будет выглядеть чудовищно. Мы надеемся, что она станет фундаментом для дальнейшего создания ужасно выглядящих игр.

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

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

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

Добрый день, уважаемые коллеги. В этой статье я бы хотел рассказать о своем аналитическом понимании различий паттернов MVC, MVP и MVVM. Написать эту статью меня побудило желание разобраться в современных подходах при разработке крупного программного обеспечения и соответствующих архитектурных особенностях. На текущем этапе своей карьерной лестницы я не являюсь непосредственным разработчиком, поэтому статья может содержать ошибки, неточности и недопонимание. Заинтригованы, как аналитики видят, что делают программисты и архитекторы? Тогда добро пожаловать под кат.