Программирование *

Введение

В доисторические времена высокопроизводительные Web-приложения можно было писать, в основном, на C или C++. Поддерживать такие приложения было не просто дорого, а очень дорого.

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

В первую очередь термины "производительность" и "надежность" относятся к Erlang. В своей нише он великолепен, но синтаксис заставляет желать лучшего. Собственно, именно поэтому появился Elixir, но речь сейчас не об этой экосистеме.

Если же немного снизить планку надежности, то здесь перед нами широкий выбор, включая Node, Go, Nim и Crystal. Можно взглянуть на типичные сравнительные данные по производительности, включая более обширные.

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

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

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

Так почему же Crystal?

В предыдущей статье Жирные программы-факторы скорости были набросаны наметки по теме — почему программы "тормозят".

Был выделен фактор памяти, как важный, но не было идей по его тестированию его “жирности” в зависимости от фреймворка. И вот, приняв на праздниках спокойное правильное состояние, я такую идею сгенерировал.

Была написана утилита, которая позволяет измерить время загрузки программы и связанные с этим расходы — дисковый ввод/вывод и потребляемую память. Ссылка в конце статьи.

Некоторые тесты под катом.

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

Список лекций:

• Лекция 1. Введение
• Лекция 2. Функции, структуры, интерфейсы. Объектная модель
• Лекция 3. Асинхронная модель
• Лекция 4. Web. Работа с сетью
• Лекция 5. Работа с СУБД
• Лекция 6. Система тестирования
• Лекция 7. Reflect or generate?
• Лекция 8. Производительность
• Лекция 9. Context, unsafe, cgo

Выход Java 9 — новой версии платформы — был отложен. Все это связано с недавними возражениями Red Hat и IBM касательно работы над системой модулей.

UPD: По итогам мероприятия мы сделали 8 предложений о работе: 5 – iOS-разработчикам, 3 – Android-разработчикам.

Привет, Хабр! Я Богдан, разработчик в iOS-команде Badoo в Лондоне. Прочитав заголовок, вы можете подумать, что в Badoo совсем с ума сошли публиковать посты на такие темы. Но пост вполне для Хабра. Мы сейчас очень активно расширяем iOS- и Android-команды и ищем разработчиков по всему миру. Естественно, Москву обойти стороной просто не можем (наш второй офис здесь). Мы хотим провести достаточно необычное мероприятие, чтобы после него обзавестись новыми коллегами.

Мы (мобильные команды Badoo) решили приехать на несколько дней в Москву и провести небольшую встречу, после которой несколько разработчиков (iOS и Android) получат предложения о работе у нас (в Лондоне). Чтобы не затягивать эту самую встречу, мы сделали онлайн-тест (он не суперсложный, а скорее чтобы понять ваш уровень и упростить и ускорить личные встречи).

Блогеры и авторы, пытающиеся быть на передовой, уже немало писали про проект Amber в Java 10. В этих статьях обязательно упоминается вывод типов локальных переменных, улучшения enum и лямбд, иногда пишут про pattern matching и data-классы. Но при этом незаслуженно обходится стороной JEP 303: Intrinsics for the LDC and INVOKEDYNAMIC Instructions. Возможно, потому что мало кто понимает, к чему это вообще. Хотя любопытно, что именно об этой фиче ребята из NIX_Solutions фантазировали на Хабре год назад.

Широко известно, что в виртуальной машине Java, начиная с версии 7, есть интересная инструкция invokedynamic (она же indy). Про неё многие слышали, однако мало кто знает, что она делает на самом деле. Кто-то знает, что она используется при компиляции лямбда-выражений и ссылок на методы в Java 8. Некоторые слышали, что через неё реализована конкатенация строк в Java 9. Но хотя это полезные применения indy, изначальная цель всё же немного другая: делать динамический вызов, при котором вы можете вызывать разный код в одном и том же месте. Эта возможность не используется ни в лямбдах, ни в конкатенации строк: там поведение всегда генерируется при первом вызове и остаётся постоянным до конца работы программы (всегда используется ConstantCallSite). Давайте посмотрим, что можно сделать ещё.

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

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

Все началось лет 8 назад. Я тогда писал одну программу для математических расчетов, и мой преподаватель указал, что я неверно именую переменные. Он был прав: x, xx, xxx сложновато различить в коде. После переименования они превратились в redSegment, greenSegment, blueSegment (в контексте задачи именование было подходящее). Потом были «Рефакторинг» Фаулера, «Совершенный код» Макконнелла, «Паттерны проектирования» банды четырех… каждый день я погружался все глубже в бездну.

В моей текущей компании никто не упоминает о правильном именовании переменных, это несерьезно. Мы обсуждаем с коллегами стили именования тестов, стоит ли использовать TestCase атрибут в nUnit, спорим о целесообразности #region в C#, пишем кастомные анализаторы для своих проектов и пьем смузи вообще всячески наслаждаемся жизнью.

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

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

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

А теперь к делу!

Привет, Хабр! Сегодня хочу поделиться своим небольшим опытом выбора инструментов для организации расчетов на будущем сервере. Отмечу сразу, что в этой публикации речь пойдет не о самом сервере, а скорее об оптимизации символьных вычислений на нем.

Задача

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

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

В последние годы мне стало казаться, что я упускаю что-то в методах разработки ПО. Весь мир радостно и с песней ускоряется, создаёт софт всё быстрее и быстрее, а я торможу. Чтобы не отставать, приходится преодолевать внутренний барьер неясной природы, действовать за границей которого выгодно но неприятно (мне). Не понятно почему выгодно. И не понятно почему неприятно.

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

Я же учился в основном по материалам, созданным в прошлом веке, «древним манускриптам», да ещё и научную фантастику читал классическую, поэтому невольно стал приверженцем «старой школы». В чем же разница?

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

+ 1 2 3
=> 6

все интуитивно понятно, вопросов не возникает. Рассказываю про булевские значения, привожу пример:

< 1 2
=> true

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

< 1 2 3
=> true
< 1 2 3 4 1 2
=> false

Все так же интуитивно понятно, вопросов не возникает и продолжаем дальше (благоразумно оставляя без рассмотрения вычисления примитивных операций на одном аргументе и вообще при отсутствии оных, а также вычитание/деление и прочие немоноидальные операции :)). Успешно миновав в докладе подобных камней, через некоторое время я подумал — а можно ли как-то изловчиться, и все-таки сделать операцию сравнения моноидом (в каком-либо смысле)? И мне кажется, мне это удалось. Заинтересовавшихся темой прошу под кат.

Примерно год назад вышла моя статья, которую можно назвать "первой частью" данной статьи. В первой части я насколько смог подробно разобрал тернистый путь разработчика-энтузиаста, который мне удалось когда-то самостоятельно пройти от начала и до конца. Результатом этих усилий стала игра жанра RTS "Земля онимодов" созданная мною в домашних условиях без движков, конструкторов и прочих современных средств разработки. Для проекта использовались C++ и Ассемблер, ну, и в качестве основного инструмента моя собственная голова.

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

Это окончание статьи, начало тут.

Примерно год назад вышла моя статья, которую можно назвать "первой частью" данной статьи. В первой части я насколько смог подробно разобрал тернистый путь разработчика-энтузиаста, который мне удалось когда-то самостоятельно пройти от начала и до конца. Результатом этих усилий стала игра жанра RTS "Земля онимодов" созданная мною в домашних условиях без движков, конструкторов и прочих современных средств разработки. Для проекта использовались C++ и Ассемблер, ну, и в качестве основного инструмента моя собственная голова.

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

Это продолжение статьи, а начало тут.

Примерно год назад вышла моя статья, которую можно назвать "первой частью" данной статьи. В первой части я насколько смог подробно разобрал тернистый путь разработчика-энтузиаста, который мне удалось когда-то самостоятельно пройти от начала и до конца. Результатом этих усилий стала игра жанра RTS "Земля онимодов" созданная мною в домашних условиях без движков, конструкторов и прочих современных средств разработки. Для проекта использовались C++ и Ассемблер, ну, и в качестве основного инструмента моя собственная голова.
В этой статье я постараюсь рассказать о том, как я решил взять на себя роль «реаниматора» и попытаться «воскресить» этот проект. Много внимания будет уделено написанию собственного игрового сервера.

Многие, наверняка, слышали о функциональном программировании, некоторые пробовали написать свой Hello World, а кто-то даже завел свой «функциональный» pet-проект. Но многие ли пользовались функциональными языками в продакшене? Какие у ФП преимущества и недостатки? Оправдывает ли парадигма функционального программирования ожидания разработчиков? На эти и многие другие вопросы нам смог ответить человек, открывший для себя преимущества функционального подхода после 20 лет ООП-разработки.

Порой кажется, что на фронте борьбы с проблемой 2038 года наступило относительное затишье. Однако время идет, и тот день, когда 32-битные значения типа time_t больше не смогут корректно отображать даты, наступит уже меньше чем через 21 год. Этот срок может показаться большим, однако сравнительно долгий жизненный цикл многих встраиваемых систем подразумевает, что некоторые из них, будучи введенными в строй в наше время, все еще будут работать, когда наступит критический момент. Арнд Бергманн — один из основных разработчиков, занимающихся этой проблемой. На конференции Linaro Connect 2017 он поделился новостями о текущем положении дел в этой области.

В прошлой статье мы рассказали, как в целом устроен фронтенд программы, обсудили технологический стек. Данную статью посвятим обсуждению Redux  —  почему мы называем его сердцем архитектуры ЕФС.