За життя

Почав працювати над продовженням IT-енциклопедії, котре початково хотів включити прямо в енциклопедію, але з певних міркувань не зробив.

Робоча назва - "Основи програмування для дітей". Принципово не буде фокусу на якійсь конкретній мові програмування. Натомість будемо обговорювати основи - ту теорію, котра дозволить будь-яку мову програмування чи бібліотеку вивчати методом порівняння (з теорією).

Зміст

Вступ

Основні поняття цифрових комп’ютерів
  • Мови програмування
  • Коментарі
  • Команди та оператори
  • Цифри та числа
  • Текстові рядки
  • Збереження даних в пам’яті. Куча і стек. Статичне і динамічне виділення пам’яті
  • Змінні та вказівники
  • Типи даних
  • Використання змінних
  • Константи
  • Операції над даними
Виконання комп’ютерних програм
  • Що таке алгоритм
  • Функції (методи, процедури). Стек викликів. Рекурсія.
  • З чого складається програма. Модулі, бібліотеки, області імен.
  • Цикли
  • Умовне виконання
  • Зворотні функції (callbacks)
  • Виключні ситуації
  • Паралельне і асинхронне виконання
Складені типи даних
  • Структури
  • Масиви
  • Набори (sets)
  • Словники (dictionaries)
  • Стек (ага, знову)
  • Переліки
  • Черги
  • Об’єкти
Об’єктне та об’єктно-орієнтоване програмування
  • Складові частини (члени) об’єкту
  • Видимість членів
далі буде

22

Із синхронічностей:

В переліку задач за номером 22 стоїть задача, можливість виконання якої значно ускладнюється тією самою Catch 22. І номер задачі присвоював сам баг-трекер, а не я.
Я зараз веду війну з колегами-американцями на тему розміру відступу при indentation - 2 чи 4 пробіли. Я за чотири, оскільки два не дуже добре видно і доводиться напружувати очі. А молодим кодувальникам пофіг, вони невідомо що економлять.

І тут я згадав, як я в 87-му році дивився на два пробіли і думав "це ж треба, як вони гаять ресурси!" . В ті часи один пробіл був цілком прийнятним відступом. А економили місце на диску і на екрані - екрани тоді були 80*25 без варіантів, мишей не було, і скролити текст було дуже незручно.
Початок тут

Ми придбали новий сертифікат (на іншу фірму) і вчора його підключили (він на токені, тому підключили ми токен до USB порту).

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

Тобто процедура підписування мало того, що не жива, так вони її ще й заривають поглибше.
Лінійка наших продуктів включає драйвери ядра (kernel-mode drivers). В Windows 10 Microsoft вирішив, що тепер робити цифровий підпис на драйвери будуть вони, а не "автори" драйверів. Ну, ок. Інтерфейс для цього діла працював до червня, потім поламався. Тупо повертає помилку підписування і пустий лог з деталями операції.

2 (два!!!) місяці ми листуємося із Microsoft'ом на цю тему, і це при тому, що два їхні департаменти використовують наші ж драйвери в своїй роботі.

Вчора (тут буде барабанний дріб і літаври в кінці) з'ясувалося, що їхній процедурі підписування не подобається символ / (слеш) в publisher name сертифіката (звідки цей символ там взявся, це окрема історія - хто знає, той зрозуміє). Проблема в тому, що слеш є частиною офіційної назви компанії (в США це дозволено) і прибрати ми його не можемо від слова "ніяк".

Далі буде ...
WebCrypto - яскравий приклад того, що станеться, коли замість професіоналів-проектувальників в індустрію приходять кодери, причому такі, котрі мало розуміються в предметі. На рівні "накодуймо алгоритмів" вони можуть. А на рівні спроектувати, як це все має використовуватися в реальному житті - вже "an authorized signature may use a key that was pre-provisioned out-of-band by the web application", а доступу до цих ключів, якщо їх збережено десь на клієнтському комп'ютері, не передбачено.
Хоча я власне програмуванням давно вже не займаюсь, для власних потреб іноді пишу якісь малі програмки або скрипти. Один з таких скриптів - SFTP клієнт для завантажування зібраних файлів наших продуктів з build server'а на web server.

Вчора неочікувано помітив, що при завантаженні певного файлу на першій спробі виникає division by zero, а друга проходить нормально. А така помилка в коді (по пам'яті) можлива лише при діленні на розмір файлу, що дорівнює 0. Дивно ...

Поліз розбиратися, а виявилося все набагато смішніше і цікавіше. В кінці завантаження для краси зроблено виведення швидкості завантаження.

До червня білд-сервер і веб-сервер жили в різних кінцях світу. А зараз вони живуть в двох VM на одному залізному сервері.

І от коли рахувалася швидкість завантаження (розмір / час), файл передавався (! по SFTP, з PKI handshake'ом!) менш ніж за GetTickCount granularity (теоретично 1 мс, практично біля 10 мс), звідки і виникало ділення на 0. Що дає мені ще один привід здивуватися, адже за нашими старими вимірами на реальній машині PKI handshake займає біля 10 мс, а тут весь файл розміром 23 Кб передається за швидший час.
Замислився над фактом, що саме розробка компонентів для ПЗ і імплементація алгоритмів привчила мене до якісної оцінки можливих наслідків, ситуацій і альтернатив для кожної дії чи події. Може й не так, як шахистів, але все одно.

Звичайний програміст, котрий пише програму, зазвичай має справу з лінійними алгоритмами, в яких є певний вхід і певний невеликий набір виходів, а програміст просто реалізує чорний ящик в найкоротший і найпростіший спосіб.

В компонентах же і в реалізаціях алгоритмів є величезна кількість можливих входів (запитів користувача компонента чи реалізації протоколу) і величезна ж кількість виходів (очікуваних поведінок компонента). І в чорному ящику (тобто нашій реалізації) необхідно не тільки пов'язати всі входи з відповідними виходами, але зробити це так, щоб не поламалися інші зв'язки. Іноді це вдається, а іноді, в складних випадках (наприклад, правильний MIME/SMIME парсер), битися доводиться роками.
Протоколу HTTP в його останній верісї (1.1) понад 10 років. Ще кілька років тому почалася робота над версією 2.0, і зокрема в неї мав увійти протокол SPDY, запропонований гуглем. Результати у вигляді стабільного драфту специфікації на HTTP 2.0 мали бути навесні цього року.

Результат? Понад 10 нових RFC, що прийшли на зміну RFC 2616 (HTTP 1.1) і пропонують ... HTTP 1.1 покращений. Жодної згадки про 2.0, SPDY тощо.

Миша, вилазь.
Лауреатом премії "Чавунний валянок" за 2013 стала компанія Embarcadero за досягнення в розробці програмного забезпечення. В новій версії компілятора для дельфі (точніше, Delphi Mobile) рядки (тип string) в них індексуються не з 1, як було 40 років до того, а з 0. Причому жодного способу відстежити проблемні місця, крім як пройтись очима по всьому коду, немає.

Для тих, хто не в курсі - це зміна з розряду зміни дорожнього руху з лівостороннього на правосторонній. Перейти можна, але возитися доведеться неймовірно довго, і помилок буде шалена кількість.
Как оказалось, сделать серверную часть HTTP транспорта можно на Java, .NET, Delphi - но не на PHP. Потому как самая популярная HTTP-серверная платформа не поддерживает (без костылей, которых по умолчанию не стоит) переменные за пределами сессии. Т.е. открыть соединение к базе в одном запросе, а попользоваться им в другом - низзя. Ура, товарищи.
Написав певну систему класів (це я проектую скелет Framework'а - писати 90% коду будуть програмісти). Почав з тестування окремих методів. Запуск тесту виявив (а) design flaw в net framework стосовно виклику event'ів (я гадав, що вони перевіряють кількість обробників - а ні фіга, (б) дві помилки в коді самого тесту, (в) помилку в коді першого ж методу, для якого я зробив тест (метод Log ;).

(написано для співробітників, публікується із незначними скороченнями)

Останні два тижні я вивчаю стан справ із розробкою для Web. Чим і хочу з вами поділитись.

15 років тому Delphi набула популярності в першу чергу завдяки концепції компонентів, тобто бібліотек коду, котрі легко вбудовувались в структуру і ієрархію класів самого засобу розробки. Загалом на ті часи на ринку був наявний обмежений перелік засобів розробки (під Windows як найбільш масову платформу), а саме Visual C++, Visual Basic, Delphi / C++Builder, пізніше Java і .NET. Все. Були ще рідкісні звірі на кшталт Access і PowerBuilder, але вони вміли використовувати COM / ActiveX. Таким чином, можна було достатньо легко "накрити" весь ринок засобів розробки.

Під web програмами ми розуміємо певний код, що виконується на веб сервері з метою взаємодії з користувачем через браузер або спеціалізовану клієнтську програму. І отут починається бардак.


Тільки в аспекті мов програмування ми маємо як вказані C++, Delphi, .NET і Java, так і такі динамічні мови як PHP, Perl, Python, JavaScript (node.js), Ruby, Scala, Groovy і пара ще більш екзотичних. Причому, наприклад Python'ів є два -- 2.5/2.7 і 3.х, котрі мають істотні розбіжності між собою і багато бібліотек не переписані ще під 3.x . PHP зараз вийшла версія 5.4, котра внесла чергові покращення і зміни (у нас на сервері використовується 5.2).

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

До цього додаються кілька типів СУБД, а саме як SQL-based MySQL (в якості найбільш популярної web-based СУБД), так і noSQL СУБД (CouchDB, MongoDB).

Оскільки клієнтською частиною є зазвичай браузер, то єдиною на сьогодні клієнтською платформою є JavaScript з усіма його недоліками (котрих чимало). Розумною альтернативою був Flash, але він на сьогодні припинив розвиватись і Adobe переключилась на HTML5 і Flash.

Конструктивно серверний код web програм може виконуватись в кількох середовищах:

1) shared хостинг. Годиться для невеликих сайтів, зазвичай надаються доступ до MySQL (кількість баз даних обмежується) і PHP чи Python чи Ruby.

2) dedicated або virtual хостінг. Вся система (фізична або віртуальна) віддається в розпорядження орендаря, котрий має адмініструвати її.

3) PaaS, Platform as a Service. Це дуже цікава річ, про неї нижче.

Що таке клауди? Їх можна поділити на клауди зі збереження даних і клаудні платформи для запуску віртуальних машин.

Клауди зі збереження даних зазвичай побудовані на базі noSQL систем і пропонують сховище для пар "ім'я-значення", де значення (BLOB) може бути довільного розміру і може мати певні додаткові атрибути. До таких клаудів відносяться відомі Amazon S3, Microsoft Azure (точніше, Azure включає в себе сервіс зі збереження BLOB'ів). Доступ до таких клаудів і операції з ними здійснюються через HTTP-подібні RESTful APIs (це GET або POST запит по HTTP).

Цікавою штукою є клаудні платформи для запуску віртуальних машин. До них відноситься Amazon EC2 і деякі менш відомі. Фактично, це той же Virtual Hosting, але з можливістю робити репліки віртуальних машин та/або змінювати параметри цих машин (кількість пам'яті, bandwidth тощо). Самі віртуальні машини створюються клієнтом і завантажуються "в клауд". Віртуальні машини підлягають адмініструванню клієнтом. Фізичне розташування машин не має істотного значення, також вони можуть бути переміщені при необхідності.

Повертаємось до PaaS. Це покращений варіант клаудних платформ для запуску VM. В PaaS постачальник сам створює і адмініструє VM. Клієнт завантажує фактично своє програмне рішення (а не VM), зроблене під платформу. Тобто клієнту надається SDK, а клієнт пише свою програму із використанням цього SDK (одну - якщо програм кілька, то це незалежні програми, які мають взаємодіяти через публічні API, оскільки вони можуть виконуватись на різних віртуальних машинах в різних кінцях світу).

На сьогодні дві основні PaaS - це Google AppEngine і Microsoft Azure. Вони мають багато схожого, але і багато відмінностей.

Google пропонує створювати програми на Java або Python (або Go, але це їхня приватна мова програмування, котра набула певної популярності в 2009-му році, але faded away з тих пір) і використовувати мішанину сервісів від гугля, таких як якесь noSQL сховище для даних або механізми content retrieval'а.

Microsoft підійшли до питання з академічною прискіпливістю і створили потужну інфраструктуру сервісів, доступних для програм, що виконуються на платформі. Також, SDK доступні для .NET, Java, node.js і PHP (є ще якийсь generic SDK, з яким я не розбирався). Фізично це працює наступним чином: програма (кожна окрема) виконується на власній віртуальній машині під управлінням Win2008 Server + IIS (в випадку, якщо програма вимагає веб-сервера), але для нас це питання не є важливим.

Таким чином, можна сказати, що не існує якогось рекомендованого або загальноприйнятого способу розробляти ПЗ для веб програм. Також, на жаль, відсутня і лідуюча платформа, на яку могли б орієнтуватись виробники компонентів. З певною натяжкою можна сказати, що є популярним PHP, але тут ми натикаємось на інший нюанс - хоча PHP можна зв'язати з кодом на С/С++, не всі користувачі мають змогу зібрати або встановити С++ модуль під свою платформу.

З технічної сторони немає сенсу глибоко вивчати будь-яку вищеперераховану технологію, хоча варто почитати базово про кожну з них, щоб розуміти, що ми маємо на ринку. Решта (framework'и тощо) вивчається за наявності конкретних задач.

Є лише дві речі в випадку саме веб-програмування, які треба вивчати і знати.

По-перше, це JavaScript як мова і як технологія. Починався JavaScript досить просто, але зараз він суттєво ускладнився - там є об'єкти і класи, активно використовуються lambda функції і інший синтаксичний мотлох, малопридатний для читання і розуміння людиною (хоча це хвороба більшості сучасних динамічних мов, чиї автори змагались, хто заплутаніше систему позначень введе).

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


Поздравляю вас, гражданин соврамши
кот Бегемот

Зашел на Apple Developer Program Member Center. Это место, где ходят разработчики (не рядовые лохи покупатели продукции Apple).

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


Во-вторых, маркетинговые тексты (http://developer.apple.com/technologies/) доставляют до уровня "пацталом":

Начиная от заголовка: Why you'll love to develop with Apple technologies (кстати, заголовок этот - картинка! Видимо, чтобы текст не копировали). Ну да, уже love to develop, "устала левая, работай правой"

The Xcode developer tools package provides you with a powerful, easy-to-use, development environment that includes everything you need to create great Mac OS X and iOS apps. Врут - выпрямитель рук разработчиков в комплект не входит, а каждому известно, что лишь прямые руки могут создавать great apps.

With Safari, you can render today’s and tomorrow’s web applications the way they are meant to be seen. Назад в будущее-4, блин. Замечу, что те же web applications чудесно и обычно качественнее рендерятся хромом и огнелисом (и тут яблочники облажались - Safari и Chrome используют один и тот же движок WebKit, но при этом хром верстает страницы более standard-compliant способом).

iOS is the world’s most advanced mobile platform, redefining what can be done with a mobile phone. По поводу most advanced можно спорить и спорить -- Windows CE / Windows Mobile имели не худшее API, а Android имеет существенно более продвинутую архитектуру. Да и в части redefining - iPhone же не является "mobile phone", а в качестве смартфона он пасет задних.

For developers, the iOS SDK and Xcode tools make it possible to create revolutionary applications that will set the bar for the next
generation of mobile applications
. Истину глаголят. Деградация качества в каждой итерации все сильнее и сильнее. Чем легче создавать программы, тем больше криворуких и тупорылых wanna-be-programmers вовлекаются в преступную деятельность разработку революционных приложений.

Mac OS X is the world’s most advanced operating system, built upon a proven UNIX foundation. Комментарий один - "врут и не краснеют". Их API suck, еще и с пересменкой -- раз в несколько лет API меняется, понятие "обратная совместимость" яблочникам неведомо в принципе.



В-третьих, криворукость вебмастеров сама по себе:

Mac Developer Program

Expiration Date: ???? 24, 2012

Вааще не проверяют, что пишут, что ли?

Местные дворяне: зачем вы это сделали?
Онегин: я либерал.
Местные дворяне: мы считаем вас опаснейшим мудаком.


«Dart предназначен для широкого числа сценариев разработки: от небольших проектов одного человека, до крупных масштабных проектов со множеством участников и компонентов. Мы считаем, что Dart отлично подойдет для создания крупных веб-приложений», - отметил Ларс Бак (Lars Bak), программный инженер Google и один из разработчиков данного языка.

Гугль медленно но верно превращается во второй Microsoft. Раньше в Microsoft изобретали велосипеды потому что предыдущую интерпретацию внутри самого же MS придумали "не они" (т.е. другая команда), теперь этим же занимается гугль. Смешали JavaScript с PHP потому что этих придумали "не они".
  • Архів

    «   Грудень 2021   »
    Пн Вт Ср Чт Пт Сб Нд
        1 2 3 4 5
    6 7 8 9 10 11 12
    13 14 15 16 17 18 19
    20 21 22 23 24 25 26
    27 28 29 30 31