Колекція хеш-функцій, реалізованих на різних мовах програмування

На днях випадково наткнувся на хорошу статтю про хеш-функції.

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

Про всякий випадок викладаю архіви тут:

• General Hash Function Source Code (C)

• General Hash Function Source Code (C++)

• General Hash Function Source Code (Pascal & Object Pascal)

• General Hash Function Source Code (Java)

• General Hash Function Source Code (Ruby)

• General Hash Function Source Code (Python)

• General Hash Function Source Code (All Languages)

• Open Bloom Filter Source Code (C++)

• Bloom Filter Source Code (Object Pascal)

• Selecting a Hashing Algorithm (Bruce J. McKenzie, R. Harries, Timothy C. Bell)

• Cryptographic Hash Functions : A Survey (S. Bakhtiari, R. Safavi-Naini, J. Pieprzyk)

Легкий старт з QML (переклад)

Хочу представити Вашій увазі мій переклад статті Getting Started Programming with QML, яку зараз уже напевно досить складно буде відшукати на сайті компанії Nokia. Незважаючи на те, що буквосполучання QML потроху відходить у небуття, і ми все частіше чуємо модні слова Qt Quick, дана стаття була моїм першим кроком у пізнаванні ще тоді нової і перспективної технологої, і вона ще й досі залишається актуальною. Але давайте все попорядку.

Що таке QML, звідки вона взялась і куди іде

Спробую дати коротку відповідь на ці три ключові питання.

QML (мова мета-об’єктів Qt) – декларативна мова програмування, схожа по своїй структурі на розмітку JSON. Основна сфера використання QML – створення динамічного графічного інтерфейсу користувача. Для програмування функціоналу використовується JavaScript. Хоча QML розроблялась для використання на мобільних пристроях, її можна використовувати і на звичайних комп’ютерах.

Звідки взялась QML? Якщо вірити Вікіпедії, офіційний стабільний реліз QML відубвася 9 листопада 2010 разом із Qt 4.7.1. Проте шлях до цієї точки був дуже довгий. Ще у далекому листопаді 2008 у статті Welcome to Kinetic вперше з’явились слова “Declarative UI” (декларативний інтерфейс користувача). У тій статт навіть наведено приклад майбутнього декларативного оголошення інтерфейсу за допомогою XML, проте цей шматок коду не має нічого спільного з сучасним станом речей. Отож проект Declarative UI стартував окремо від Qt. Уже в травні 2009 з’явились перші приклади програм, створених з використанням нової декларативної мови, котра отримула назву QML. За основу було взято нотацію JSON, оскільки вона є більш читабельною ніж XML. Основною особливістю технології було те, що з її допомогою можна було написати програми без жодного рядка коду на C++. Інтерфейс користувача створювався об’єктами QML, логіка – на JavaScript. Таку програму не потрібно було компілювати – вона інтерпретувалася, а отже була кросплатформенною. Разом із вдосконаленням бібліотеки підтягувалося і середовище розробки – в Qt Creator появився дизайнер QML, а також інструмент для налагодження JS-коду.

Куди іде QML? У листопаді 2010 року відбувся перший стабільний реліз Qt Quick – платформи, основою для якої стала QML. Qt Quick включає у себе Qt Declarative – середовище виконання програми, QML – мова створення інтерфейсу, JavaScript – як додатковий засіб реалізації логіки програми, а також набір інструментів для розробки та налагоджування програм. Слід зауважити, що Qt Quick можна використовувати поряд із іншими модулями Qt у зичайних С++-програмах. Отож, Qt Quick зараз є однією з найперспективніших технологій у сім’ї Qt. Незважаючи на свою молодість, вона пройшла серйозний шлях розвитку і зараз повністю готова для повноцінного використання як на мобільних пристроях так і на звичних нам персональних комп’ютерах.

Історія одного перекладу

Якось сидячи на роботі без діла і, як завжди, перечитуючи блоги  про Qt я наткнувся на статтю. Автор пропонував взяти участь у конкурсі перекладів. У якості вихідного матеріалу подавалися дві статті: Getting Started Programming with Qt та Getting Started Programming with QML. Кожен бажаючий міг вибрати одну із статтей, перекласти її на свою рідну мову, опублікувати на офіційному вікі-сайті Qt і отримати гарантований приз: фірмову футболку. Переможець вибирався випадковим чином і отримував смартфон Nokia N900. Оскільки на той час я знав QML тільки на початковому рівні, я обрав саме статтю про QML. Переклад зайняв близько тижня, і ось зараз у мене у шафі лежить пам’ятна футболка, яка приїхала до мене із Фінляндії. Радує те. що головний приз дістався нашому співвітчизнику, який займався перекладом першої статті і зробив це дуже якісно.

Підсумовуючи

Не хочу тратити дурно Ваш і свій час на розповіді, тому перейду зразу до моралі своєї байки.

Мене часто запитують: Навіщо перекладати технічні статті, адже люди, яким вони будуть цікаві знають англійську мову? Зазвичай так і є. Проте наведу кілька аргументів, які спонукали і далі спонукають мене до перекладу:

1. Перекладаючи статтю, читач (який є і автором водночас) краще усвідомлює текст. Читаючи на іноземній мові ми часто пропускаємо цілі звороти, які здаються нам неважливими. При якісному перекладі ми заглиблюємось у текст і отримуємо набагато детальніше бачення матеріалу.
2. Перекладаючи текст ми покращуємо своє знання як англійської так і української мови. Оскільки для якісного перекладу недостатньо тільки розуміння тексту іноземною мовою. Потрібно вміти влучно описати матеріал своєю мовою, щоб і зміст не втратився і текст не виглядав кострубатим (як з Google Translate).
3. Статті, подібні до тих, які я перекладаю зазвичай читають не професіонали, а початківці. У ситуації коли читач тільки починає ознайомлюватись з тематикою статті, іноземна мова ускладнює розуміння матеріалу.
4. Ну і нарешті, наявність україномовної документації у тій чи іншій галузі позитивно сприяє на формування спільноти спеціалістів у цій галузі.

Отож, досить філософії, переходимо до теорії і практики QML. Приємного читання і успіхів у розробці! І звичайно, запрошую Вас взяти участь у перекладі матеріалів по Qt на українську мову.

Легкий старт з QML

Herb Sutter: Розподіл – корінь усіх суперечок

Спільне використання спричиняє очікування і накладні витрати, і є природним ворогом масштабованості

Що спільного є у наступних ситуаціях:

• Двоє дітей малюють крейдою.
• Три покупці супермаркету додають вершки у каву.
• Чотири процеси виконуються на ядрі центрального процесора.
• П’ять потоків оновлюють об’єкт захищений мютексом.
• Шість потоків, які виконуються на різних процеcорах оновлюють одну чергу без блокувань.
• Сім модулів використовують один спільний об’єкт, для якого ведеться підрахунок користувачів.

Відповідь: у всіх ситуаціях, кілька користувачів ділять між собою ресурс, який вимагає координування доступу через те, що не кожен користувач може використовувати його у один і той же момент – і такий розподіл є коренем усіх суперечок, які понижують продуктивність усіх користувачів. (Примітка: Єдиним видом спільних ресурсів, які не створюють суперечок є об’єкти, які за своєю суттю не вимагають синхронізації, тому що всі користувачі можуть використовувати їх одночасно без будь-яких обмежень, тобто, тобто вони не належать до ресурсів описаних вище. Для прикладу, незмінний об’єкт можуть зчитувати кілька потоків або процесорів одночасно без синхронізації доступу.)

У цій статті автор свідомо зосереджує увагу на одній важливій проблемі, а саме змінних спільних об’єктах у пам’яті, які завжди є вузьким місцем при масштабуванні на багатоядерних системах. Проте не забуваймо що основне твердження, а саме “розподіл викликає суперечки” є загальним принципом, який не обмежується спільною пам’яттю чи навіть комп’ютерною сферою.

Невід’ємна ціна розподілу

Основна суть проблеми одним реченням: Спільне використання вимагає очікування своєї черги, а також відповіді на ресурсоємкі запитання.

Як тільки певний об’єкт стає спільним у певний спосіб, що не дозволяє необмеженого одночасного використання, ми зобов’язані частково або повністю контролювати доступ до нього. Даний факт завжди виступає як “червоне світло” – контроль доступу є основним ворогом “паралелізму” та “масштабованості”. Ця проблема не обмежується спільним доступом до пам’яті, вона також проявляється у тому, що “одна дитина не може використовувати синю крейду поки нею користується інша дитина”, а також “тільки один процес може одночасно здійснювати запис у файл” тощо.

Необхідність контролю черговості доступу означає дві речі: інколи потрібно чекати своєї черги, а також зазвичай потрібно задавати собі питання “Чи можу я використовувати ресурс зараз?”. Обчислення відповіді на будь-яке питання у ПЗ потребує процесорного часу, проте вище згадане питання вимагає набагато більших витрат ніж здається. Зазвичай для обчислення відповіді на це питання потрібно задіяти комунікацію між різними програмами, процесами, потоками, а також процесорами, ядрами та іншими апаратнимим компонентами. Надлишкові витрати на таку комунікацію зазвичай неможливо побачити в коді програми, оскільки вона здійснюється на рівні ядра системи або на апаратному рівні.

Готуємось до Qt Essentials: 1.1. Кросплатформенність

Сьогодні починаю цикл статтей про підготовку до здачі тесту Qt Essentials. На дантй момент це єдина офіційна сертифікаційна програма від Nokia для знавців Qt. Старт програми Qt Certification Advanced Exams планується на перший квартал 2011 року. Що дає успішна здача Qt Essentials?

1. Як і будь-яка сертифікація, Qt Essentials – це ще один додатковий “плюс” до Вашого резюме.
2. Підвищення заробітньої плати. Наявність сертифікатів, які є доказом  професіоналізму працівника завжди позитивно впливає на його винагороду.
3. Сертифікат Qt Essentials – це ще один крок Вашого професійного розвитку.

Що потрібно для успішної здачі тесту?

1. Досвід роботи з платформою Qt. Зазвичай 2-3 років достатньо.
2. Зареєструватись на сайті для здачі екзамену (безкоштовно).
3. Знайти найближчий центр сертифікації, оплатити екзамен та здати його.

Громадяни України мають знижку при складанні тесту (як жителі країни, що розвивається), тому одна спроба обійдеться всого у 89 євро.