Процес парсинга ускладнюється істотними витратами часу на обробку даних. Багатопоточність допоможе в рази збільшити швидкість обробки даних. Сайт для парсингу — «Довідник купюр світу», де отримаємо валюту у співвідношенні до інших.

Читати далі →



Привіт! Мене звуть Паша Матлашов. Я Director of Game Server Development Department в ігровій компанії Plarium.

Сьогодні на прикладі наших проектів я розповім про особливості кешування, підводних каменях і про те, як їх обійти.

Читати далі →

Друге пришестя ГОСТ 28147-89: Чесні тести

Друге пришестя ГОСТ 28147-89

Близько десяти років тому симетрична криптографія, заснована на ГОСТ 28147-89, перестала задовольняти потребам апаратних платформ за швидкісними параметрами. Швидкості криптоперетворень, забезпечувані алгоритмами реалізованими на регістрах загального призначення процесорів, не встигали за швидкостями обміну інформацією в мережах та на дискових накопичувачах.
З іншого боку (американської), з'явився AES-256, який показував набагато кращі швидкісні параметри при тій же мірі криптостійкості.

У цій ситуації 8 центр ФСБ почав роботи над новим блоковим шифром, який отримав згодом назву «Коник» від початкових літер прізвищ авторів.
Спочатку це була безперспективна затія, оскільки повторювалася логіка шифру AES, але якщо той був прискорений апаратно в процесорах Інтел і АМД, то у Коника такого апаратного прискорення на цих процесорах звичайно бути не могло.
Так що Коник, це класичний приклад викинутих на вітер бюджетних грошей, і не малих…

Читати далі →

7 найнеприємніших проблем в програмуванні

image
Відомо, що на старих картах, на незвіданих територіях, часто поміщали зловісне попередження: «Тут живуть дракони». Вероятносенс цього попередження полягав у тому, що не варто входити в це простір світу, не будучи готовими битися з вселяє жах противником. Все що завгодно може статися на цих загадкових просторах, і нерідко таке «що завгодно» може закінчитися дуже погано.

Програмісти, можливо, є кілька більш цивілізованими, ніж середньовічні лицарі — однак це зовсім не означає, що сучасний технічний світ не має своїх технічних драконів, що чекають нас в непередбачених місцях: складні проблеми, які спливають саме тоді, коли підходить термін здачі роботи або в моменти особливо високих навантажень і відповідальної роботи; конкуренти, які прочитали керівництво і знають, що недостатньо добре реалізовано; злі «біси», які знають, як використовувати неліквідовані до кінця баги і дефекти програм, причому дізнаються це часто відразу ж після того, як програма здана до використання.

Знаходяться люди, які спокійно сплять вночі, согреваемые своєю наївною впевненістю, що комп'ютери цілком передбачувані і невтомно видають потоком правильні відповіді. Як же мало їм відомо! Незважаючи на серйозні зусилля розробників чіпів, творців мов і мільйонів програмістів, є ще в програмуванні небезпечні хащі, які можуть погубити навіть самих просунутих з програмістів і розробників.

Ось сім з страхітливих куточків світу програмування, на яких легко можна написати: «Тут живуть дракони».

Читати далі →

Розділяються покажчики і багатопоточність. І знову про них, вкотре


Глава із книги "Сучасне програмування на C++" називається "В сто перший раз про інтелектуальних покажчиках". Все б нічого, але книга була видана в 2001 році, так чи варто в черговий раз повертатися до цієї теми? Мені здається що якраз зараз і стоїть. За ці п'ятнадцять років змінилася сама точка зору, той кут під яким ми дивимося на проблему. У ті далекі часи тільки-тільки вийшла перша де-факто стандартна реалізація — boost::shared_ptr<>, до цього кожен писав собі реалізацію за потреби і як мінімум уявляв собі деталі, сильні і слабкі сторони свого коду. Всі книги з C++ в той час обов'язково описували одну з варіацій розумних покажчиків в найдрібніших деталях.
Зараз нам даний стандарт, і це добре. Але з іншого боку, вже не потрібно розуміти що там всередині, замість цього досить три рази повторити мантру "використовуйте розумні покажчики скрізь де ви б використовували звичайні покажчики", і це вже не так добре. Я підозрюю що далеко не всі віддають собі звіт що даний стандарт — лише один з можливих варіантів інтерфейсу, не кажучи вже про різницю між реалізаціями різних вендорів. При виборі стандарту був зроблений вибір між різними можливостями враховує різні фактори, але, оптимальний чи ні, цей вибір очевидно не один.
А ще на stackoverflow наприклад знову і знову задається питання — "потокобезопасны чи розумні покажчики із стандартної бібліотеки?". Відповіді даються зазвичай категоричні, але якісь мало інформативні. Якщо б я наприклад не знав про що йде мова, то напевно б не зрозумів. І до речі, все порівняно нові книги описують новий стандарт C++ цього питання теж приділяють мало уваги.
Так давайте ж спробуємо зірвати покриви і розберемося з деталями.
Читати далі →

Готуємо багатопоточність з core.async

image
Усе більше набирає популярність патерн використання каналів при створенні
багатопоточних додатків. Ідея не нова, її дизайн закладено ще в далекому 1978 році
у вигляді CSP.Найбільш відома реалізація зараз повсюдно використовується в Golang.
Ми ж у статті розглянемо реалізацію CSP в core.async для Clojure, якщо цікаво, ласкаво просимо під кат.

Читати далі →

Вирішуємо проблеми з RAII у std::thread: cancellation_token як альтернатива pthread_cancel і boost::thread::interrupt

Стаття розглядає проблеми у std::thread, попутно вирішуючи давній спір на тему "що використовувати: pthread_cancel, булев прапор або boost::thread::interrupt?"
Проблема
У класу std::thread, який додали в C++11, є одна неприємна особливість — він не відповідає з ідіомі RAII (Resource Acquisition Is Initialization). Витяг з стандарту:
30.3.1.3 thread destructor
~thread();
If joinable() then terminate(), otherwise no effects.
Чим нам загрожує такий деструктор? Програміст повинен бути дуже акуратний, коли мова йде про руйнування об'єкта
std::thread
:
void dangerous_thread()
{
std::thread t([] { do_something(); });
do_another_thing(); // may throw - can cause termination!
t.join();
}


Читати далі →

Шпаргалка Java програміста 4. Java Stream API



Незважаючи на те, що Java 8 вийшла вже досить давно, далеко не всі програмісти використовують її нові можливості, когось зупиняє те, що робочі проекти занадто складно перевести з Java 7 або навіть Java 6, когось використання у своїх проектах GWT, хтось робить проекти під Android і не хоче або не може використовувати сторонні бібліотеки для реалізації лямбд та Stream Api. Однак знання лямбд та Stream Api для Java програміста часто вимагають на співбесідах, ну і просто буде корисно при переході на проект де використовується Java 8. Я хотів би запропонувати вам коротку шпаргалку по Stream Api з практичними прикладами реалізації різних завдань з новим функціональним підходом. Знання лямбд і функціонального програмування не потрібно (я постарався дати приклади так, щоб все було зрозуміло), рівень від самого базового знання Java і вище.

Також, так як це шпаргалка, стаття може використовуватися, щоб швидко згадати як працює та чи інша особливість Java Stream Api. Короткий перелік можливостей основних функцій дано на початку статті.

Для тих хто зовсім не знає що таке Stream ApiStream API це новий спосіб працювати зі структурами даних у функціональному стилі. Найчастіше з допомогою stream в Java 8 працюють з колекціями, але насправді цей механізм може використовуватися для самих різних даних.

Stream Api дозволяє писати обробку структур даних в стилі SQL, то якщо раніше завдання отримати суму всіх непарних чисел з колекції вирішувалася наступним кодом:
Integer sumOddOld = 0; 
for(i Integer: collection) {
if(i % 2 != 0) {
sumOddOld += i;
}
}

То з допомогою Stream Api можна вирішити таку завдання у функціональному стилі:
Integer sumOdd = collection.stream().filter(o -> o % 2 != 0).reduce((s1, s2) -> s1 + s2).orElse(0);

Більш того, Stream Api дозволяє вирішувати завдання паралельно лише змінивши stream() на parallelStream() без всякого зайвого коду, тобто
Integer sumOdd = collection.parallelStream().filter(o -> o % 2 != 0).reduce((s1, s2) -> s1 + s2).orElse(0);

Вже робить код паралельним, без всяких семафорів, синхронізацій, ризиків взаємних блокувань тощо


Читати далі →

Створюємо REST-сервіс на Rust. Частина 5: обробники, рефакторинг, і макроси

Всім привіт!

Ми продовжуємо писати веб-сервіс на Rust. Зміст:

Частина 1: прототип
Частина 2: читаємо INI; multirust
Частина 3: оновлюємо базу з консолі
Частина 4: переходимо до REST API
Частина 5 (ця): обробники, рефакторинг, і макроси

Тепер ми розглянемо власне обробники запитів до API і перепишемо попередній, страшний код. І взагалі, це остання стаття з циклу, тому тут будуть рефакторинг, стиль, макроси і все-все-все. Це найдовша частина.

Читати далі →

Паралельна обробка великого селекта в декількох сесіях

Уявіть: є селект, який повертає записи, кожну з яких потрібно обробити, і то багато записів, то обробка кожного запису займає багато часу, а процес обробки одного запису не залежить від процесів інших записів.
Класичний приклад для того, щоб задіяти багатопоточність або у випадку баз даних виконувати обробку декількох сесіях. У Оракле для цього використовується hint /*+ parallel () * / pipelined functions. Це здорово, але якщо у вас Oracle standard edition(де parallel не працює) або ви хочете обробити не кожну запис окремо(з міркувань, що краще накопичити роботу, а потім в bulk, одним ударом, виконати), а поділити весь висновок селекта на шматки і кожен обробити окремо?

Читати далі →