Содержание

• Введение
• Величины, типы и операторы
• Структура программ
• Функции
• Структуры данных: объекты и массивы
• Функции высшего порядка
• Тайная жизнь объектов
• Проект: электронная жизнь
• Поиск и обработка ошибок
• Регулярные выражения
• Модули
• Проект: язык программирования
• JavaScript и браузер
• Document Object Model
• Обработка событий
• Проект: игра-платформер
• Рисование на холсте
• HTTP
• Формы и поля форм
• Проект: Paint
• Node.js
• Проект: веб-сайт по обмену опытом
• Песочница для кода

Некоторые люди, столкнувшись с проблемой, думают: «О, а использую-ка я регулярные выражения». Теперь у них есть две проблемы.
Джейми Завински

Юан-Ма сказал: «Требуется большая сила, чтобы резать дерево поперёк структуры древесины. Требуется много кода, чтобы программировать поперёк структуры проблемы».
Мастер Юан-Ма, «Книга программирования»

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

В этой главе мы обсудим такой инструмент – регулярные выражения. Это способ описывать шаблоны в строковых данных. Они создают небольшой отдельный язык, который входит в JavaScript и во множество других языков и инструментов.

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

Приходилось ли вам или вашим знакомым/друзьям полностью менять свою профессию? Как вы/они это делали?
А в каких условиях и за какое время? С каким бекграундом по новой желаемой профессии вы пришли на первое собеседование?

Примем следующие условия:

1. Тяжелая финансовая ситуация (семье нужны деньги)
2. Кризис в стране. На текущей работе резкое уменьшение зарплаты. Кризис. Финансов меньше, проектов меньше, премий тоже меньше.
3. У других работодателей похожая ситуация.
4. Необходимо как можно скорее сменить профессию.
5. Бекграунд по новой профессии есть, но он не очень велик/глубок.

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

1. Устроиться в нормальную, стабильную фирму, а не в ту, «куда возьмут».
2. Чтобы были отличные перспективы, мощный и умный коллектив.
3. Чтобы была возможность очень быстро расти и развиваться.

Можно создать очень привлекательное резюме. И пытаться произвести впечатление на работодателя всякими-разными способами.

А может, просто быть искренним? Поделюсь своим опытом.

Для ленивых и не желающих возиться, сдувать пыль с бубна по настройке exim4/postfix/sendmail предлагается простейший сборщик почты написанный на Python^[1].

Его работа заключается в сборе всей почты, посылаемой этому фейковому smtp серверу и складывании её в указанную папку /tmp/mails в виде файлов писем nobody@mail.local.1 с порядковым номером.

Если у вас есть некий процесс, который может выполняться долго и возвращать несколько промежуточных результатов с течением времени, то Реактивные Расширения (.NET Framework Reactive Extensions) позволят вам упростить код и лучше управлять им.



В большинстве случаев вы просто вызываете метод и получаете результат на выходе. Но некоторые процессы устроены по-другому. Например, метод может выполняться в течение продолжительного промежутка времени. Или, что хуже, метод не только выполняется долго, а ещё и нерегулярно возвращает какие-то промежуточные результаты во время исполнения. Конечно, в том числе и для этого, в .NET Framework есть события, с помощью событий один объект может вызвать метод второго объекта, передавая некоторую информацию, в тот момент времени, когда это необходимо.

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

Пример редактора уровня в игре.

Если вы когда либо играли в игры типа Guitar Hero, Osu или Bit Trip Runner вы знаете, как сильно погружает в «поток» простая зависимость геймплея от музыки играющей на фоне. Удивительно, что таких игр, на самом деле не так уж и много. Кроме того, такая синхронизация может быть полезна для создания спецэффектов, но тем не менее почти нигде не встречается, кроме обозначенных выше игр типа rhythm. Вот и я решил воспользоваться таким бесхитростным приемом в собственной игре, а также поделиться наработками.

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

СД: НЧ

Без плагинов Brackets не лучше других редакторов, но с ними его стоит хотя бы попробовать.

Введение

Не так давно на Хабре было опубликовано множество статей, касающихся тем или иным образом редактора Brackets. У многих людей сразу же появились вполне справедливые вопросы:

1. Чем он лучше используемого мной %EDITOR_NAME%?
2. Много ли под него плагинов?
3. Стоит ли связываться или лучше использовать какую-нибудь известную IDE или текстовый редактор?

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

Содержание

• Введение
• Величины, типы и операторы
• Структура программ
• Функции
• Структуры данных: объекты и массивы
• Функции высшего порядка
• Тайная жизнь объектов
• Проект: электронная жизнь
• Поиск и обработка ошибок
• Регулярные выражения
• Модули
• Проект: язык программирования
• JavaScript и браузер
• Document Object Model
• Обработка событий
• Проект: игра-платформер
• Рисование на холсте
• HTTP
• Формы и поля форм
• Проект: Paint
• Node.js
• Проект: веб-сайт по обмену опытом
• Песочница для кода

Отладка изначально вдвое сложнее написания кода. Поэтому, если вы пишете код настолько заумный, насколько можете, то по определению вы не способны отлаживать его.
Брайан Керниган и П.Ж.Плауэр, «Основы программного стиля»

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

Мастер Юан-Ма, «Книга программирования».

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

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

Часто проблема возникает в тех ситуациях, возникновение которых программист изначально не предвидел. Иногда этих ситуаций нельзя избежать. Когда пользователя просят ввести его возраст, а он вводит «апельсин», это ставит программу в непростую ситуацию. Эти ситуации необходимо предвидеть и как-то обрабатывать.

Последние два года я решаю все задачи исключительно на Cython. Это вовсе не значит, что я пишу на Питоне, а потом «Ситонизирую» это с использованием различных деклараций типов, нет, я просто пишу на Cython. Я использую «сырые» структуры и массивы C (а иногда и векторы C++) и маленькую обёртку вокруг malloc/free, которую я написал сам. Код работает практически так же быстро, как C/C++, потому что это и есть код на C/C++, украшенный синтаксическим сахаром. Это код на C/C++ с функционалом Python именно там, где мне это нужно и где я этого хочу.

Закончились праздники и выходные, но не поводы радоваться. Что может быть приятнее, чем узнать о долгожданном обновлении любимой Java IDE? Мы с нетерпением ждали четыре долгих дня, чтобы удивить вас этим приятным сюрпризом. Встречайте IntelliJ IDEA 14!



Рассказывая о том, чем мы занимались большую часть года, мы всякий раз переживаем и волнуемся. Каждая новая версия IntelliJ IDEA поднимает планку всеобщих ожиданий. И все-таки каждое обновление — еще один шанс для нас доказать, что совершенству нет предела. Удалось ли на этот раз — судить вам!

Уважаемые друзья,

Мы продолжаем Мировой тур RAD Studio XE7 и в этом квартале мы стартуем с Минска, в котором будем 26 ноября, далее 2 декабря ждите нас в Нижнем Новгороде, а окончание тура будет 10 декабря в Красноярске.

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

В ходе мероприятия спикеры расскажут как:

• Разрабатывать кроссплатформенные приложения с помощью нового дизайнера единого интерфейса;
• Улучшать производительность настольных и мобильных приложений с помощью библиотеки параллельных вычислений, используя преимущества многоядерных процессоров;
• Как обеспечить использование мобильной инфраструктуры стандартными сервисами
• Сбалансировать ИТ инфраструктуру и масштабировать работу с данными за счет включения корпоративных сервисов

Как-то незаметно для меня прошли все эти новые веяния в виде активных мониторов, на которые пользователь может тыкать пальцами. И знать бы о них не знал, кабы месяца три назад начальство не приобрело себе ноутбук, который можно порвать на две части (экран отдельно, клавиатура отдельно), причем не Surface какой-то, пропиаренный MS, а уже самый проходной у пользователей – от ASUS, за гораздо меньшие деньги (относительно).
Да и закуплен был данный девайс не просто так – задача выросла оттуда, откуда и не ждали.

Де юре: мы проводим огромное количество семинаров в месяц, и вот именно на них, нашим лекторам начали демонстрировать несовместимость нашего ПО с этим пресловутым тачем.

Де факто: на почту саппорта начали сыпаться гневные письма пользователей плана – «я два раза тапнула, а оно не тапнулось, может не так тапнула?»
А начальство все это скрупулезно отслеживало на своем «порватом» ноутбуке и готовило ТЗ.

И вот настал тот день. Мне на рабочий стол был воздвигнут третий монитор, 23 дюйма от LG (с поддержкой Touch ввода аж 10 пальцами) и поставлена задача – это должно заработать в течении трех дней!

А работаю то я в XE4 – беда.

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

Многие разработчики решают идти по пути наименьшего сопротивления, возложив эту задачу, например, на СУБД. Скажем, один процесс положил данные в БД, второй прочитал, обработал — положил еще и так далее.
Про обмен через файлы в наши годы уже стыдно говорить, но и такое случается.
Другие же программисты пытаются создать какое-то свое, специализированное решение и, как правило, выбирают сокеты.

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

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

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

Это вторая часть моих размышлений на тему «Python, каким бы я хотел его видеть», и в ней мы более подробно рассмотрим систему типов. Для этого нам снова придётся углубиться в особенности реализации языка Python и его интерпретатора CPython.

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

Python всегда гордился своей реализацией системы типов. Я помню, как много лет назад читал документацию, в которой был целый раздел о преимуществах утиной типизации. Давайте начистоту: да, в практических целях утиная типизация — хорошее решение. Если вы ничем не ограничены и нет нужды бороться с типами данных по причине их отсутствия, вы можете создавать очень красивые API. Особенно легко на Python получается решать повседневные задачи.

Практически все API, которые я реализовывал на Python, не работали в других языках программирования. Даже такая простая вещь, как интерфейс для работы с командной строкой (библиотека click) просто не работает в других языках, и основная причина в том, что вам приходится беспрестанно бороться с типами данных.

Не так давно поднимался вопрос добавления статической типизации в Python, и я искренне надеюсь, что лёд, наконец, тронулся. Постараюсь объяснить, почему я против явной типизации, и почему надеюсь, что Python никогда не пойдёт по этому пути.

Quotient filter — это вероятностная структура данных, позволяющая проверить принадлежность элемента множеству. Она описана в 2011 г. как замена фильтру Блума. Ответ может быть:
— элемент точно не принадлежит множеству;
— элемент возможно принадлежит множеству.

Сотрудник Mozilla Николас Нетеркот опубликовал заметку с очень чётким объяснением, почему размер буфера памяти для программы нужно увеличивать экспоненциально, а не линейно.

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

Так вот. Представим, что наш изначальный 1-байтный буфер растёт по 1 байту до тех пор, пока не достигнет размера 1 МиБ. Сколько памяти мы задействовали для него кумулятивно?

1 + 2 + 3 + … + 1,048,575 + 1,048,576 = 549,756,338,176 байт

Неслабо, да?

Сегодня Аарон Тюрон — разработчик, недавно присоединившийся к разработке Rust в Mozilla — объявил об отсрочке реализации какого-либо механизма исключений, кроме уже существующего макроса try! и типа Result, до неопределённого момента после первого релиза языка программирования Rust.

Это означает, что в Rust 1.0 будут отсутствовать исключения первого класса — то есть, полностью интегрированные с другими фичами языка.

Для обработки ошибок в данной момент в Rust существует тип Result { Ok(value), Err(why) } и макрос try!. Тип Result представляет из себя перечисление (enum), похожее на Option { Some(value), None } и связанное с ним по смыслу. Вариант None типа Option говорит об отстутствии значения, а вариант Err(why) типа Result уточняет, почему значение отсутствует.

Rust предлагает возвращать тип Result из функций, чтобы передавать значение возврата или причину, по которой значение вернуть не удалось. Макрос try! в свою очередь позволяет автоматически возвращать Err(why) из текущей функции, если вызов другой функции не удался (применяется к объекту типа Result).

Приводим доклад khroliz Игоря Хрола, компания Wargaming, Минск, с конференции SQA Days 15.

Видео доклада:
vimeo.com/93944414

Презентация:
www.slideshare.net/slideshow/embed_code/33725306#

Я 8 лет работаю в этой отрасли, и я считаю, что у нас есть проблемы )

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

Базовые принципы

Этот текст является продолжением поста о библиотеке Strutext обработки текстов на языке C++. Здесь будет описана реализация лексического уровня представления языка, в частности, реализация морфологии.

Когда-то давно я решил «потрогать» Fortran. Единственную задачу которую я придумал — генерация фракталов (заодно и OpenMP в Fortran'е можно было бы попробовать). В процессе написания я часто сталкивался с проблемами, решение которых приходилось додумывать самому (например в интернете не так много примеров использования чисел двойной точности или бинарной записи в файл). Но рано или поздно все проблемы решились, и я хочу написать этот текст, который возможно кому-нибудь поможет.

Писать я буду на диалекте Fortran 90, но с GNU расширениями (те же числа двойной точности).

Вступление

REST — очень интересный метод для работы с объектами на сервере. Реализация CRUD-интерфейса средствами REST проходит легко и просто! Сегодня я попытаюсь показать какие из подходов в REST/CRUD по моему мнению ошибочны и пагубны для проекта.