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

Глава из книги "Современное программирование на C++" называется "В сто первый раз об интеллектуальных указателях". Все бы ничего, но книга была издана в 2001 году, так стоит ли в очередной раз возвращаться к этой теме? Мне кажется что как раз сейчас и стоит. За эти пятнадцать лет поменялась сама точка зрения, тот угол под которым мы смотрим на проблему. В те далекие времена только-только вышла первая де-факто стандартная реализация — boost::shared_ptr<>, до этого каждый писал себе реализацию по потребности и как минимум представлял себе детали, сильные и слабые стороны своего кода. Все книги по C++ в то время обязательно описывали одну из вариаций умных указателей в мельчайших деталях.

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

А еще на stackoverflow например снова и снова задается вопрос — "потокобезопасны ли умные указатели из стандартной библиотеки?". Ответы даются обычно категоричные, но какие-то мало информативные. Если бы я например не знал о чем идет речь, то наверное бы не понял. И кстати, все сравнительно новые книги описывающие новый стандарт C++ этому вопросу тоже уделяют мало внимания.

Так давайте же попробуем сорвать покровы и разберемся с деталями.

Недавно TechCrunch подробно рассказал о новом витке развития языка программирования Dart. Google как разработчики языка теперь не только делают большую ставку на использование дарта в создании своих ключевых сервисов (AdWords, AdSense), но и намерены более активно влиять на рост всей экосистемы, в том числе и в России, и поддерживать компании, использующие Dart в своих проектах. Первая встреча, посвященная использованию Dart в России пройдет 30 ноября в Петербурге, в офисе компании Wrike.


На встрече мы обсудим новый виток в развитии языка Dart, поговорим с разработчиками языка из Google, сможем задать им свои вопросы. Мы также уделим внимание необходимой инфраструктуре для работы с языком, успешным кейсам и проектам, сделанным на Dart, и выясним, каковы особенности перехода на дарт со скриптовых (JavaScript) и типизированных (C#) языков.

29 сентября в Москве прошла мини-конференция JetBrains Night: 7 часов разработчики из JetBrains рассказывали разработчикам из других компаний о том, что компания делает, зачем, и что будет делать дальше, а потом отвечали на вопросы, обсуждали общие проблемы и вообще делились опытом (т.е. слушали, как разработчики из других компаний рассказывают им о том, что они делают и почему им удобно или пока еще не очень удобно делать это с помощью того, что делает JetBrains).

На Хабре мы постепенно публикуем видео всех докладов, чтобы можно было в комментариях обсудить то, что не успели обсудить на JetBrains Night, особенно с теми, кто не смог приехать лично.

В предыдущих постах Дмитрий Жемеров рассказывал про язык Kotlin (там до сих пор продолжается умеренно живая дискуссия в комментариях), а затем Максим Мазин и Валерия Андрианова делились практическими советами по интеграции серверных продуктов и использовании новых Agile-досок.

Если вы раньше не знали, что билды в TeamCity можно настроить с помощью DSL (например, чтобы проще было менять и использовать эти настройки в других проектах), то

Вводная

Устали от LAMPов, MAMPов, ручной настройки, конфликтов? Хотите получить полностью настроенное и готовое к работе окружение для web разработки с Nginx, DB(Mysql, Pgsql, Redis), PHP7 на борту и с настроенным xDebug и все это за 5 минут? Stacker идет на помощь!

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

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

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

Я начал использовать Rails в 2006, сразу после скрикаста Давида Ханссона, в котором он с помпой представил миру фреймворк. Мы написали первую версию Scribd на Rails 0.7. Тогда, когда фреймворк не имел даже миграций.

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

Данная статья (и я надеюсь что серия статей) посвящена нестандартным расширениям языков C и C++, которые существуют практически в каждом компиляторе.

Языковые расширения — это дополнительные возможности и фичи языка, не входящие в стандарт, но тем ни менее поддерживаемые компиляторами. Исследовать эти расширения очень интересно — в первую очередь потому, что они возникли не на пустом месте; каждое расширение — результат насущной необходимости, возникавшей у большого числа программистов. А мне интересно вдвойне — поскольку мне нравятся языки программирования и я разрабатываю свой, часто оказывается что многие мои идеи реализованы именно в расширениях языка. Стандарты языков C и C++ развиваются крайне медленно, и порой, читая описание расширений, так и хочется воскликнуть «ну это же очевидно! почему этого до сих пор нет в стандарте?».

Языковые расширения — это такая «серая», теневая область, про которую обычно мало пишут и мало знают. Но именно этим она и и интересна!

Предварительно могу сказать, что будут рассмотрены компиляторы общего назначения gcc, msvs, clang, intel, embarcadero, компиляторы для микроконтроллеров iar и keil, и по возможности многие другие компиляторы. Больше всего расширений в GCC, что не удивительно — свободная разработка способствует воплощению разных языковых фич. К тому же, информация по расширениям GCC вся собрана в одном месте, а информацию по остальным компиляторам придется собирать по крупицам. Поэтому начнем с GCC.

«Я был молод и мне были нужны деньги.»
— Сильвестр Сталлоне


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

Такое случилось со мной в 2000 году. И это мой груз навсегда.

Первую строчку кода я написал в 6 лет. Хотя я не вундеркинд. Тогда мне очень помог отец. Но я уже попался на крючок. Мне это нравилось.

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

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

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

В 21 у меня была постоянная работа программистом в интерактивной маркетинговой компании в Торонто, Канада.

Компания была основана доктором медицины и многие из ее клиентов были крупными фармацевтическими компаниями.

Недавно я работал над новой C#-диагностикой V3119 для статического анализатора PVS-Studio. Назначение диагностики — выявление потенциально небезопасных конструкций в исходном коде C#, связанных с использованием виртуальных и переопределенных событий. Давайте попробуем разобраться: что же не так с виртуальными событиями в C#, как именно работает диагностика и почему Microsoft не рекомендует использовать виртуальные и переопределенные события?

Здравствуйте! Сегодня мы познакомимся с новым семейством дешевых и малопотребляющих ПЛИС от Lattice Semiconductor семейств iCE40LP/HX/LM, научимся работать с фирменным компилятором iCEcube2 и редактором кода Sublime Text 3, а также программировать чип на отладочной плате Lattice iCEstick с помощью прошивки, написанной на SystemVerilog.

Все будет сопровождаться подробными инструкциями и скриншотами.

Многие начинают путь к изучению программирования, открыв поздним вечером Google. Обычно ищут что-то вроде «Как выучить…». Но как тот, кто ищет подобное, решает, какой именно язык программирования выбрать?

Кто-то, начитавшись сайтов и блогов крупнейших компьютерных компаний, рассуждает так: «В Кремниевой долине что ни слово –  то Java. Думаю, это – то, что мне нужно». Бывает и так: «Haskell. Он ведь на пике популярности. Страшно подумать, что будет дальше. Определённо – Haskell». И даже так: «Этот суслик на логотипе Go – такая няшка. Хочу знать Go».

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

Используемые компоненты:

• REACT-CPP;
• AMQP-CPP;
• RapidJSON;
• LevelDB;
• Easylogging++.

Для примера буду делать микросервис для выдачи рейтинга игроков. От ядра системы в микросервис приходят следующие сообщения:

• player_registered(id,name);
• player_renamed(id,name);
• player_won(id, points).

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

Сейчас в самом разгаре недельная онлайн-конференция Geek Week. Послезавтра она завершится, и это будет единственный день конференции в оффлайн-формате. В московском офисе Mail.Ru Group вы сможете послушать выступления IT-специалистов из разных компаний и вживую пообщаться с единомышленниками. Программа — под катом.

Весной прошёл первый митап сообщества rustycrate.ru в штаб-квартире «Лаборатории Касперского». А в мире Rust за прошедшие полгода произошло много интересного: были реализованы футуры и асинхронный ввод-вывод поверх них, сделан первый выпуск системы поддержки IDE, появилась инкрементальная сборка. Иными словами, опять есть о чем поговорить.



Поэтому 22 ноября в 19:00 мы собираемся провести еще один митап сообщества, и приглашаем всех, кого интересует этот язык программирования, в наш московский офис. На встрече мы планируем обсудить опыт реального применения Rust в задачах системного программирования и тестирования, поговорим о том, что получается хорошо, а что — не очень. Докладчики из сообщества расскажут, как Rust помогает им и как его готовить, чтобы он помогал вам.

Обнаружил эту статью в черновиках. Если её не опубликовать сейчас, то уже никогда – она безвозвратно устареет и место ей только на помойке.

Не так давно компания Apple представила WatchKit Framework для разработки приложений под свои фирменные часы Apple Watch. На данный момент iOS 8.3 SDK очень ограничен – весь код выполняется на iPhone/iPad, а на часах находится только интерфейс и картинки. Таким образом, при любом взаимодействии с элементами интерфейса – код выполняется на iOS-устройстве, а сигнал проходит от часов до устройства по Bluetooth и обратно. Создание анимаций из заранее нарезанных кадров – задача довольно примитивная и уже разжевана во многих блогах. Под катом речь о создании динамической анимации, кадры который подготавливаются на CoreGraphics.

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

Большинство из нас, впервые столкнувшись с данной проблемой, начинают забивать в поисковых системах что-то типа: «regexp online generator» и к своему великому сожалению осознают что гугл сломался все результаты в поиске являются сервисами для проверки корректности уже составленного регулярного выражения (или я плохо гуглил).

А как же составить это самое регулярное выражение?

До недавнего времени существовало 2 ответа на этот вопрос:

1. Изучить документацию по регулярным выражениям и составить регулярку самому
2. Попросить кого-то более опытного сделать это за вас

Теперь, после нескольких месяцев разработки, рад представить и 3-й ответ:

» Генератор регулярных выражений

История

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

Запылилась за месяц у меня на полке Raspberry Pi 3 со встроенным Wi-Fi. Ресурсов процессора и объема памяти уже достаточно для запуска ресурсоемких программ. Как же быстро разработать и запустить на ней свою программу состоящую всего из одного небольшого файла с отправкой фото на почту и веб сервером мониторинга?



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

Привет Хабр! Это вторая часть перевода статьи про подсчет различных судоку.



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

Как обычно, мои комментарии выделены курсивом или спрятаны под спойлеры. Под спойлерами можно найти самое интересное — куски кода, которые верифицируют все числа, полученные в повествовании.

Приглашаем вас на очередную встречу Java-разработчиков ThinkJava #4. Спикеры нашего ThinkJava-сообщества переплыли моря и океаны, чтобы побывать на SpringOne Platform в Лас-Вегасе, и теперь готовы поделиться привезёнными знаниями и своим опытом со всеми гостями ThinkJava #4. Мы посвящаем эту встречу вопросам облачных вычислений.

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