Веб ожидает большое будущее.

Вчера Брендан Айк “взорвал” сообщество веб-разработки: веб получит новый низкоуровневый бинарный компилируемый формат, который будет работать гораздо лучше, чем JavaScript.

Google, Microsoft, Mozilla, а также несколько независимых специалистов работают над новым проектом в W3C WebAssembly Community Group, и то, над чем они работают, совсем не маленькая вещь.

ABBYY FineReader – программа для распознавания текстов, которая в России известна многим ещё со студенческих времён. В этом году FineReader исполняется 22 года, он немного моложе нашего словаря Lingvo. Как так вышло, что вместе со словарём молодые программисты из BIT Software (в то время ABBYY называлась именно так) занялись распознаванием текстов? И что помогло Файну стать одной из самых узнаваемых на рынке программ?

На самом деле, всё очень логично. Если бы не Lingvo, FineReader’а могло бы и не быть. Началось всё с масштабного и амбициозного комплекса под названием Lingvo Systems. С его помощью человек мог отсканировать текст на одном языке, пропустить его через программу и получить перевод, правда, черновой, но для понимания смысла его было достаточно.

В 4 часа утра, без объявления войны… Нет, не так: проверяю почту с утра, вижу непрочитанные сообщения с фриланса. Лезу на сайт отвечать — там меня встречает огромный баннер во весь экран «Вся работа только через сделку без риска! Обмен личными контактами запрещён!» — по привычке закрыл такой баннер, практически не читая, кликаю на ссылку сообщения и вижу вот такую вот картину:



Для тех, кто free-lance.ru не пользуется, поясню: «Сделка без риска» — это их функционал проведения сделок через сайт, подразумевающий обязательный %, который отстёгивается им за эту работу + бюрократизацию всего процесса, включая проверку обстоятельств работы, тз и прочего. Теперь, значит, фриланс решил сделать это обязательным для всех.

Что же получается:

1. новшество, кардинально меняющее всю механику взаимоотношений на сайте, было внедрено без консультаций с аудиторией — оно и понятно, любой опрос на эту тему дал бы результат «99% против»
2. новшество было внедрено без предупреждения — просто поставили перед фактом. Т.е. я, пользователь, который уже платит фрилансу деньги за аккаунт pro регулярно сейчас лишён возможности пользоваться сайтом — вот так завис над этой формой с предупреждением и не решаюсь ставить галочку, потому что
3. фриланс официально заявляет, что не только читает ЛИЧНЫЕ сообщения на сайте, но и считает себя вправе их модерировать. До такой наглости даже признанные империи зла и добра не доходили.

Идиома RAII (Resource Acquisition Is Initialization) берет свое начало в языке С++ и заключается в том, что некоторый ресурс захватывается в конструкторе объекта, и освобождается в его деструкторе. А поскольку деструктор локальных объектов вызывается автоматически при выходе из метода (или просто из области видимости) не зависимо от причины (нормальное завершение метода или при генерации исключения), то использование этой идиомы является самым простым и эффективным способом написания сопровождаемого C++ кода, безопасного с точки зрения исключений.

При переходе к «управляемым» платформам, таким как .NET или Java, эта идиома в некотором роде теряет свою актуальность, поскольку освобождением памяти занимается сборщик мусора, а именно память была самым популярным ресурсом, о котором приходилось заботиться в языке С++. Однако поскольку сборщик мусора занимается лишь памятью и никак не способствует детерминированному освобождению ресурсов (таких как дискрипторы операционной системы), то идиома RAII все еще применяется и в .NET, и в Java, пусть мало кто из разработчиков знает об этом замысловатом названии.

Когда говорят, что инновации Made in Russia — это только спорные проекты вроде «Ё-мобиля» паровоза Черепановых, однозначно неоспоримые вроде космических ракет и прочих полу- и совсем неполу-военных изделий, или голые идеи на экспорт — не верьте. У нас есть чем похвастать, и мне за это гордо.

За прошедшие XX-надцать лет моя компания выросла из мелкого местечкового мухомора в топы рейтингов IDC и верхне-правильный угол «магического квадрата» Гартнера. Красивый офис на главной улице страны, Слон Дали на ресепшене, почти 3 тысячи человек в штате, 30+ офисов по всему миру… и прочие хвалилки. Но здесь не про это.

Почему это получилось? Много причин. Например, мой неизменный принцип: пробовать, пытаться и не бояться ошибок. А еще ― партнёрская программа, работа с ритейлерами, онлайнерами, столицами и провинциями ― там много чего было, но и это не по данной теме.

Все перечисленное — вторично (да простят меня те, кто несёт эту службу). Первично — наши технологии и продукты (в смысле, просто софт, а не «софт+всё остальное»). Поскольку если есть софт — всё остальное можно настроить. Если же нет главного — товара, — то всё остальное нет смысла строить. Иначе бизнес (продажи) будет либо одноразовым, либо коррумпированным, что мне претит категорически и фатально.



Итак, софт. Чем здесь можно гордиться? Есть чем! Расскажу вам, уважаемые хабравчане, про «Шестёрку».

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

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

Почему так получается, что инженеры пользуются спросом, а «эффективные менеджеры» которые ими руководят – совсем никому не интересны?

— Для чего нужны монады?
— Для того, чтобы отделить чистые вычисления от побочных эффектов.
(из сетевых дискуссий о языке Haskell)

Шерлок Холмс и доктор Ватсон летят на воздушном шаре. Попадают в густой туман и теряют ориентацию. Тут небольшой просвет — и они видят на земле человека.
— Уважаемый, не подскажете ли, где мы находимся?
— В корзине воздушного шара, сэр.
Тут их относит дальше и они опять ничего не видят.
— Это был математик, – говорит Холмс.
— Но почему?
— Его ответ совершенно точен, но при этом абсолютно бесполезен.
(анекдот)

Когда древние египтяне хотели написать, что они насчитали 5 рыб, они рисовали 5 фигурок рыб. Когда они хотели написать, что насчитали 70 людей, они рисовали 70 фигурок людей. Когда они хотели написать, что насчитали в стаде 300 овец, они… — ну, в общем, вы поняли. Так и мучились древние египтяне, пока самый умный и ленивый из них не увидел нечто общее во всех этих записях, и не отделил понятие количества того, что мы подсчитываем, от свойств того, что мы подсчитываем. А потом другой умный ленивый египтянин заменил множество палочек, которыми люди обозначали количество, на значительно меньшее количество знаков, короткой комбинацией которых можно было заменить огромное количество палочек.

То, что сделали эти умные ленивые египтяне, называется абстракцией. Они подметили нечто общее, что свойственно всем записям о количестве чего-либо, и отделили это общее от частных свойств подсчитываемых предметов. Если вы понимаете смысл этой абстракции, которую мы сегодня называем числами, и то, насколько она облегчила жизнь людям, то вам не составит труда понять и абстракции языка Haskell — все эти непонятные, на первый взгляд, функторы, моноиды, аппликативные функторы и монады. Несмотря на их пугающие названия, пришедшие к нам из математической теории категорий, понять их не сложнее, чем абстракцию под названием «числа». Для их понимания совершенно не требуется знать ни теорию категорий, ни даже математику в объёме средней школы (арифметики вполне достаточно). И объяснить их тоже можно, не прибегая к пугающим многих математическим понятиям. А смысл абстракций языка Haskell точно такой же, как и у чисел — они значительно облегчают программистам жизнь (и вы пока даже не представляете, насколько!).

Привет, Хабр!

В феврале мы публиковали перевод крутой статьи "Почему научиться программировать так чертовски тяжело?", которую теперь показываем новичкам. Да, научиться программировать – это целая история, длинная, с кучей разных этапов, с эмоциональными взлетами и падениями. Мы все через это проходили (или еще проходим – так держать!).

К сожалению, нет такого момента, когда можно встать и заявить, что «я закончил обучение и теперь я программист!». Учиться придется всю жизнь, и всю жизнь вы будете встречать неведомые проблемы, сталкиваться с совершенно непонятными ситуациями и спрашивать «какого хрена?!» даже будучи профессиональным программистом с многолетним стажем.

Сегодня мы публикуем перевод заметки «Почему программировать так тяжело?». Тем, кто еще изучает основы программирования и разработки будет полезно узнать, что их ждет в будущем. А опытным разработчикам будет просто приятно взглянуть на реальность и покивать головой.



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

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

В этой статье мы рассмотрим два способа поиска с помощью регулярных выражений. Один широко распространён и используется в стандартных интерпретаторах многих языков. Второй мало где применяется, в основном в реализациях awk и grep. Оба подхода сильно различаются по своей производительности:



В первом случае поиск занимает A?ⁿAⁿ времени, во втором — Aⁿ.

Степени обозначают повторяемость строк, то есть A?³A³ — это то же самое, что и A?A?A?AAA. Графики отражают время, требуемое для поиска через регулярные выражения.

Обратите внимание, что в Perl для поиска строки из 29 символов требуется более 60 секунд. А при втором методе — 20 микросекунд. Это не ошибка. При поиске 29-символьной строки Thompson NFA работает примерно в миллион раз быстрее. Если нужно найти 100-символьную строку, то Thompson NFA справится менее чем за 200 микросекунд, а Perl понадобится более 10¹⁵ лет. Причём он взят лишь для примера, во многих других языках наблюдается та же картина — в Python, PHP, Ruby и т. д. Ниже мы рассмотрим этот вопрос более детально.

Наверняка вам трудно поверить приведённым данным. Если вы работали с Perl, то вряд ли подмечали за ним низкую производительность при работе с регулярными выражениями. Дело в том, что в большинстве случаев Perl обращается с ними достаточно быстро. Однако, как следует из графика, можно столкнуться с так называемыми патологическими регулярными выражениями, на которых Perl начинает буксовать. В то же время у Thompson NFA такой проблемы нет.

Возникает логичный вопрос: а почему бы в Perl не использовать метод Thompson NFA? Это возможно и следует делать, и об этом пойдёт далее речь.

В преддверии своего доклада на конференции PGCONF.RUSSIA 2015 я поделюсь некоторыми наблюдениями о важных различиях между СУБД MySQL и PostgreSQL. Этот материал будет полезен всем тем, кого уже не устраивают возможности и особенности MySQL, а также тем, кто делает первые шаги в Postgres. Конечно, не стоит рассматривать этот пост как исчерпывающий список различий, но для принятия решения в пользу той или иной СУБД его будет вполне достаточно.

Здравствуйте, меня зовут Владимир и я анонимный разработчик десктопных приложений под Windows. В этом месте все должны сказать «Здравствуй, Владимир!», а кто-то может быть добавит «Молодец, что осознал!». А потом все похлопают. Нет, правда, иногда от чтения Хабра у меня возникают именно такое ощущение, что нормально, нет, даже не «нормально», а допустимо и одобряемо сегодня писать только микросервисы для каких-то стартапов, которые будут по какому-то REST API отдавать данные какому-нибудь фронтенду на Ангуляре, который и будет, наконец, показывать пользователю что-то невероятно полезное, вроде таблицы с аггрегированными отзывами о стрижках пуделей с возможностью посмотреть на гуглокартах где бы в вашем городе можно было сделать именно такую стрижку вашему пуделю (несуществующему). А никаких других программ писать уже нет-нет, никак нельзя! Что за чушь?!

Да, многое сегодня происходит в вебе и на мобильных устройствах, но, знаете ли, далеко не всё. Значительная часть приложений по-прежнему является десктопным софтом. И даже (о, ужас!) не под Mac Os или Linux, а под тот самый богомерзкий Windows. И, знаете ли, софт этот живёт, развивается, поддерживается и является ежедневным рабочим инструментом миллионов людей. И никуда он мигрировать не собирается, потому что есть причины, по которым иногда именно десктопное приложение является лучшим вариантом.

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

Процессоры, используемые в наших продуктах — это, в основном, 16- и 32-битные микроконтроллеры Microchip, имеющие RAM от 8 до 32 кБ, и ROM от 128 до 512 кБ, без MMU. Иногда, для самых простых устройств, используются еще более скромные 8-битные чипы.

Очевидно, что у нас нет (разумных) шансов использовать ядро Linux. Так что нам нужна какая-нибудь RTOS (Real-Time Operating System). Находятся даже люди, которые не используют никаких ОС в микроконтроллерах, но я не считаю это хорошей практикой: если железо позволяет мне использовать ОС, я ее использую.

Несколько лет назад, когда мы переходили с 8-битников на более мощные 16-битные микроконтроллеры, мои коллеги, которые были гораздо более опытными, чем я, рекомендовали вытесняющюю RTOS TNKernel. Так что это — та ОС, которую я использовал в разных проектах в течение пары лет.

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

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

Содержание:

• I. Перебор настоящих массивов
  
  1. Метод forEach и родственные методы
  2. Цикл for
  3. Правильное использование цикла for...in
  4. Цикл for...of (неявное использование итератора)
  5. Явное использование итератора
  
  
• II. Перебор массивоподобных объектов
  
  1. Использование способов перебора настоящих массивов
  2. Преобразование в настоящий массив
  3. Замечание по объектам среды исполнения
  
  

На SlashDot и других западных площадках активно обсуждается интересная статья Charlie Demerjian «Microsoft has failed». Она написана сложным английским, но поднимает актуальные вопросы, не ограничиваясь, к примеру, вопросами удобства или неудобства плиточного интерфейса. Хоть про автора говорят, что часто пишет слишком мрачно, но на мой взгляд, материал — в стиле доброго сарказма неравнодушного человека, и вполне достоин публикации и обсуждения на хабре. Переведена 1в1, без изменений.

Microsoft терпит неудачу?

Nov 14, 2012
Charlie Demerjian @ semiaccurate.com

У Microsoft большие проблемы: 2 основные продуктовые линейки терпят неудачу, и поиски виноватых ускоряются. В этот раз за провал Windows 8 винят Стива Синофского (Steve Sinofsky), но настоящая проблема заключается в модели поведения, которую иллюстрируют такие действия.
Microsoft сильно не соответствует реалиям сегодняшнего дня: те немногие рынки, на которых она играет, испаряются с поражающей воображение скоростью. Давно известная привычка компании отгораживаться от остального мира, игнорируя мнения окружающих, работает неплохо до тех пор, пока нет достойной альтернативы, и такая стратегия была для компании основополагающей настолько давно, что ничего другого не осталось. Модель работает, но с ростом стен безразличия растет раздражение клиентов, тем самым увеличивая ценность возможных альтернатив. Этот цикл повторяется до тех пор, пока альтернатив нет. Как только они появляются, то всё рушится с устрашающей быстротой.

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

Всё что Вам нужно – это пара старых очков, нож для бумаги и растворитель для краски.

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

Многие из нас сталкиваются с такой задачей, когда нужно запускать своё приложение при запуске компьютера. Конечно можно поместить ярлык в автозагрузку, но как-то это неправильно. Да к тому же если комп перегрузился, а пользователь не залогинелся, то и ваше приложение тоже не запустится.

Самым верным решением в данной ситуации является написание Windows сервиса.

Пример создания сервиса в Studio 2010, .Net C# под катом

Каждый знает, что бывают «десятикратные» программисты, которые в 10 раз более производительны, чем программист обыкновенный. Мы не можем измерить производительность, поэтому и не знаем, правда ли это. Но на самом деле людей необыкновенно производительных существует немало, достаточно, чтобы доказать существование «десятикратного программиста».

Как же они этого добиваются?

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

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.