Всем привет!
Как-то раз мне пришла в голову идея проанализировать вакансии размещенные на Хабре. Конкретно интересовало, есть ли зависимость между размером зарплаты и наличия высшего образования. А еще сейчас у студентов идет сессия (в том числе и у меня), то возможно кому-то уже надоело трепать нервы на экзаменах и этот анализ будет полезен.
Так как я программист на .Net, то и решать эту задачу — парсить объявления на Хабре я решил на C#. Вручную разбирать строки html мне не хотелось, поэтому было придумано найти html-парсер, который помог бы осуществить задачу.
Забегая вперед скажу, что из анализа ничего интересного не вышло и сессию придется сдавать дальше :(
Но зато немножко расскажу про весьма полезную библиотеку Html Agility Pack

Перевод поста Стивена Вольфрама "Untangling the Tale of Ada Lovelace".
Выражаю огромную благодарность Кириллу Гузенко KirillGuzenko за помощь в переводе и подготовке публикации.

---

Содержание

Ранние годы Ады
Чарльз Бэббидж
Уровень развития этой области
Возвращаемся к Аде
Возвращаясь к Бэббиджу
Статья Ады
После статьи
После смерти Ады
Что стало с Бэббиджем?
Повторное открытие
О чем на самом деле писала Ада
Вычисление чисел Бернулли
Бэббидж vs. Ада?
Секретный ингредиент Бэббиджа
В большем масштабе
А что, если...
Какими они были?
Заключение

---

Ада Лавлейс родилась 200 лет назад. Для некоторых она является знаменательной фигурой в истории вычислительной техники; для других — изрядно переоцененной личностью. В течение долгого времени я пытался разобраться, как всё было на самом деле. И вот, к её двухсотлетию, я решил разобраться в том, что называл для себя "тайной Ады".

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

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

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

Доброго времени суток, хабр!

Так как мне скоро предстоит разрабатывать веб-приложение, а писать на интерпретирумых языках как-то нет желания, тем более, что есть такие ЯП как D и Go, возникло желание сравнить их производительность при работе с веб (в сети не нашёл тестов, которые были бы свежими). Для D это vibe.d, а для Go, как я понял, не используются фреймворки. Так как Go я знаю менее чем «никак» решил не выпендриваться: тестовые приложения просто отдают страничку с некоторым текстом (ни баз данных, ни сложного роутинга, ни изображений).

Нагрузка давалась с помощью Apache Benchmark.

В жизни каждого мужчины наступает момент, когда трафик растёт и сервак умирает необходимо задуматься об оптимизации. В последнем дайджесте PHP (№ 40) была упомянута ссылкой статья «How GZIP Compression Works». Исходя из статистики, 56% веб-сайтов используют GZIP. Я надеюсь, эта статья раскроет перед читателем достоинства этой технологии.

Все будет быстро. Это выступление Анатолия Левенчука, в последнее время не дает мне покоя. Успехи глубинного обучения в последний год говорят о том, что все очень быстро изменится. Слишком долго кричали волки-волки говорили «искусственный интеллект», а его все не было. И вот, когда он, наконец, приходит к нам, многие люди этого просто не осознают, думая, что все закончится очередной победой компьютера в очередной интеллектуальной игре. Очень многие люди, если не все человечество, окажется за бортом прогресса. И этот процесс уже запущен. Думаю, что в этот момент меня не очень будет интересовать вопрос, который вынесен в заголовок статьи. Но, пока этот момент еще не настал, попытаюсь поднять этот потенциально спорный вопрос.

Программируя уже более 25 лет, застал достаточно много различных концепций, что-то смог попробовать, еще больше не успел. Сейчас с интересом наблюдаю за языком Go, который можно отнести к продолжателям “линейки языков Вирта” — Algol-Pascal-Modula-Oberon. Одним из замечательных свойств этой цепочки является то, что каждый последующий язык становится проще предыдущего, но не менее мощным и выразительным.

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

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

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

Написать этот пост меня вдохновила замечательная статья в блоге Gaffer on Games «Reading and Writing Packets» и неуёмная тяга автоматизировать всё и вся (особенно написание кода на C++!).

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

• Выбор формата. Если бы мы писали простенькую игру на JavaScript, нас бы устроил JSON или любой его самописный родственник. Но мы пишем серьёзную многопользовательскую игру, требовательную к трафику; мы не можем позволить себе отправлять ~16 байт на float вместо четырёх. Значит, нам нужен «сырой» двоичный формат. Однако, двоичные данные усложняют отладку; было бы здорово, если бы мы могли менять формат в любой момент, не переписывая целиком все наши функции чтения/записи.
• Проблемы безопасности. Первое правило сетевой игры: не доверяй данным, присланным клиентом! Функция чтения должна уметь оборваться в любой момент и вернуть false, если что-то пошло не так. При этом использовать исключения считается неважной идеей, поскольку они слишком медленные. Мамкин хакер пусть и не сломает ваш сервер, но вполне может ощутимо замедлить его беспрерывными эксепшнами. Но вручную писать код, состоящий из if'ов и return'ов, неприятно и неэстетично.
• Повторяющийся код. Функции чтения и записи похожи, да не совсем. Необходимость изменить структуру пакета приводит к необходимости поменять две функции, что рано или поздно приведёт к тому, что вы забудете поменять одну из них или поменяете их по-разному, что приведёт к трудно отлавливаемым багам. Как справедливо замечает Gaffer on Games, it is really bloody annoying to maintain separate read and write functions.

Всех интересующихся тем, как Бендер выполнил своё обещание и при этом решил обозначенные проблемы, прошу под кат.

Недавно мне понадобилось написать 2-3-дерево и я начал искать информацию в русскоязычном интернете. К сожалению, ни на хабре, ни на других ресурсах я не смог найти достаточно полную информацию на русском языке. На всех ресурсах было одно и то же: свойства дерева, как вставляются ключи в дерево, поиск в дереве и иногда простой пример, как удаляется ключ из дерева; не было реализации.

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

Когда, за бутылкой пива, я заводил разговор о нейронных сетях — люди обычно начинали боязливо на меня смотреть, грустнели, иногда у них начинал дёргаться глаз, а в крайних случаях они залезали под стол. Но, на самом деле, эти сети просты и интуитивны. Да-да, именно так! И, позвольте, я вам это докажу!

Допустим, я знаю о девушке две вещи — симпатична она мне или нет, а также, есть ли о чём мне с ней поговорить. Если есть, то будем считать это единицей, если нет, то — нулём. Аналогичный принцип возьмем и для внешности. Вопрос: “В какую девушку я влюблюсь и почему?”

Можно подумать просто и бескомпромиссно: “Если симпатична и есть о чём поговорить, то влюблюсь. Если ни то и ни другое, то — увольте.”

Еще в XIX веке было известно, что если любую замкнутую петлю, лежащую на двумерной поверхности, можно стянуть в одну точку, то такую поверхность легко превратить в сферу. Так, поверхность воздушного шарика удастся трансформировать в сферу, а поверхность бублика – нет (легко вообразить себе петлю, которая в случае с бубликом не стянется в одну точку). Гипотеза, высказанная французским математиком Анри Пуанкаре в 1904 году, гласит, что аналогичное утверждение верно и для трехмерных многообразий.

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



Читают лекцию доценты механико-математического факультета МГУ к. ф-м. н. Александр Жеглов и к. ф.-м. н. Федор Попеленский.

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

Одним из проектов, над которым работала моя команда, был новый движок представления для ASP.NET.

ASP.NET MVC всегда поддерживал концепцию “движка представлений”, собственно он представляет из себя заменяемые модули, которые реализуют выбор различного синтаксиса шаблона. Сегодня, стандартный движок представлений для ASP.NET MVC использует аналогичные файлы, что и ASP.NET Web Forms — .aspx/.ascx/.master. Существуют и другие популярные ASP.NET MVC движки представлений — Spark и NHaml.

Новый движок представлений, над которым мы работаем, оптимизирован под генерацию HTML-кода, фокусируясь на коде шаблона. Кодовое имя для данного движка – “Razor”, первая бета-версия будет доступна уже скоро.

Продолжая свое знакомство с БД PostgreSQL, с уже имеющимися навыками работы в БД MySQL, обнаружил ряд интересных полезных особенностей которые на практике часто не хватало в MySQL. Цель этого обзора не в создании бесконечного спора, что лучше, а дать легкое сравнение, которое обычно обсуждается программистами на обеденном перерыве в ближайшей кафешке. В сравнении обретаются новые знания и опыт, поэтому оно того стоит.

Скучное вступление

Не так давно, мне довелось участвовать в разработке некоего программно-аппаратного комплекса для одной американской компании. Разрабатывал я бэкенд, немного фронтенд, сращивал устройства с облаком (IoT то бишь). Стек технологий был обозначен четко. Ни в право, ни в лево — enterprise, одним словом. В определенный момент меня перекинули в помощь на фронтенд POS (Point of Sale) веб приложения.

Проблема. Становится интересней

Всё бы ничего, но веб приложение разрабатывалось для работы в 6 тыс. офисах по всей территории Америки (для начала). Где, как оказалось, с интернетом могут быть проблемы. Да да, в той самой, продвинутой Америке! Проблемы с покрытием не только проводного интернета, но и мобильной связью! Т.е. плохой интернет канал (часто, мобильный) — вполне себе обычная история для небольших американских городов.

А это же POS… Тут, понимаешь, клиенты стоят, надо инвойс быстро распечатать… Тормозов быть не должно! И livesearch… Были обсуждения, прикидки, в итоге — не стали грузить бэкенд запросами (трафик, опять же). Сошлись на том, что веб приложение должно по-максимуму подгружать данные и делать, тот же поиск, локально. Речь идет, конечно, о данных, размер которых позволяет это сделать.

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

В далеком 2012, когда цена на нефть еще была трехзначной, а трава зеленее, майкрософтом был выпущен .NET 4.5, а с ним и конструкция async/await. Про неё написано уже довольно много статей (Async в C#), а большинство разработчиков C# хорошо её изучили. Но все ли варианты использования были рассмотрены, можно ли выжать из await немного больше?

Самым очевидным вариантом использованием этой конструкции является ожидание завершения некой асинхронной операции. Первое, что приходит на ум — это ожидание ввода-вывода. Например, мы послали запрос клиенту и ожидаем ответа, тогда используя await мы сможем продолжить выполнение кода после получения ответа, а сам код при этом будет выглядеть синхронным. Но что если во время ожидания возникнет необходимость прервать выполнение этой операции? Тогда нам придется использовать CancellationToken, причем если таких операций несколько, то токены необходимо будет линковать или использовать один общий токен. При этом причина отмены будет скрыта от кода, использующего этот CancellationToken. Кроме отмены, код должен поддерживать обработку потери соединения, таймаута, возвращаемых ошибок и т.д.

В классическом варианте это выльется в использование CancellationToken для обработки отмены, try catch для обработки разрыва соединения и код анализа возвращенных данных, для оценки результата запроса. Но можно ли уместить всё это в единой парадигме? В этот статье я предлагаю рассмотреть альтернативный подход, основанный на событийной модели с использованием синтаксического сахара async/await.

Как известно, контрол WebBrowser это просто обертка над ActiveX компонентом Internet Explorer. Следовательно он предоставляет доступ к полноценному layout-движку со всеми современными плюшками. А раз так, то попробуем (сам не знаю правда зачем) на его основе сделать пользовательский интерфейс для обычного windows-приложения.

Можно, конечно, было бы запустить в этом же процессе мини веб-сервер (на HttpListener например) и ловить запросы через него, но это слишком просто, скучно и неспортивно. Попробуем обойтись без сетевых компонентов, just for fun.

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

Тема работы с временными метками в PostgreSQL плохо раскрыта в русскоязычных профильных публикациях в Интернете и служит частым источником проблем в работе программистов. Предлагаю вашему вниманию перевод материала от Hubert Lubaczewski, автора популярного зарубежного блога depesz.com. Надеюсь, статья будет для вас полезна!



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

Как и обещал, продолжаю тему(раз, два) управляемой печати PDF из под .NET в векторном формате. О теоретических аспектах работы с PCL я рассказал в предыдущей статье, настало время разобрать программу для вывода на принтер PDF файла в векторе. Наше приложение будет полезно, например, когда нужно распечатать пачку многостраничных бланков или анкет на бумаге разных цветов и разной плотности. Если мы научимся управлять лотками принтера, избавим себя от ручного прокладывания страниц ;) В шаблоне будет указан номер лотка, из которого принтер заберет бумагу для текущей страницы. Причем шаблон будет применяться к документу циклически: если в документе 32 страницы, а в шаблоне 4, то шаблон повторится 8 раз для Simplex режима и 4 раза для Duplex.

Привет Хабр, хочу пригласить всех на небольшую экскурсию по языку D. Зачем? Ну зачем люди вообще на экскурсии ходят — чтобы развлечься, увидеть что-то новое и вообще — это интересно. D трудно назвать новым или хотя бы молодым, однако в последние пару лет шло бурное развитие, в сообщество пришел Андрей Александреску и быстро стал ведущим разработчиком, с его способностью предвидеть тренды он внес огромный вклад в концепции самого языка и особенно в стандартную библиотеку.

С самого своего возникновения D позиционировался как улучшенный C++ (по крайней мере в моем прочтении истории). Возможность отбросить некоторые устаревшие конструкции и внести вместо них то новое, что не могло быть реализовано в классическом C++, и одновременно бережное сохранение низкоуровневых возможностей, таких как встроенный ассемблер, указатели и использование библиотек С, делают D уникальным претендентом на звание «следующего в ряду C — C++ — ...». Ну это с моей точки зрения, сам я (наверное вежливо было бы добавить «к сожалению») абсолютно моноязычен, много лет пишу на C++ и любые попытки познакомиться с другими языками неизбежно заканчивались крепким здоровым сном. Однако я слышал от представителей других конфессий что D для них тоже интересен как язык, так что на экскурсию приглашаю всех.

Что я буду показывать? По D уже написано несколько очень хороших книг, поэтому я решил просто взять функцию getopt() из стандартной библиотеки и посмотреть на ее код, неоценимо полезное упражнение позволяющее оживить прочитанное в книгах. Почему именно эту функцию? Ну, она же всем знакома и системно независима, я лично ее использую 3-4 раза в неделю и в деталях представляю как она могла бы быть написана на 3-х различных языках. Кроме того, автором кода значится Александреску, я много раз видел учебные примеры его кода в книгах и никогда не видел кода написанного в продакшн, любопытно же. В конце я конечно же не удержался и написал свой велосипед (естественно улучшенный), в данном случае это совершенно уместно и не менее полезно чем разбор чужого кода.

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

Знакомый линуксоид упрекнул меня, мол, в винде ни переключения языка Caps Lock'ом нет, ни даже раскладку нельзя отредактировать. Посмотрел я, и правда, все раскладки содержатся в файлах C:\Windows\System32\kbd*.dll, и редактировать такое hex-редактором ну никак не назвать удобным.

Как достичь удобства? Для переключения раскладок Caps Lock'ом можно использовать всякие навесные программы, тяжёлые вроде Punto Switcher, или простые вроде lswitch. Для редактирования раскладок есть MSKLC, но он малофункционален и неудобен, а аналоги вроде KbdEdit или KLM32 платные.

И тогда я решил написать на flat assembler'е код, собирающий DLL раскладки.