Стендап Сьогодні

Що я зробив, що я хочу зробити, і що це все значить.
Повсякденні здобутки в форматі стендапу.
Детальніше в статті

Підписатись на RSS
📢 Канал в Telegram @stendap_sogodni
🦣 @stendap_sogodni@shevtsov.me в Федиверсі

Раніше

Пізніше

12.10.2023

Що робити, якщо підліток хоче програмувати?

Тільки не пропонувати рідні Ruby on Rails або Go або Java… Мрії підлітків можуть бути різні, але навряд чи це мікросервіс або система бронювання квитків. Скоріше це буде щось візуальне. Гра чи ще щось таке захопливе. Щось круте.

Я бачу дві вимоги до мови та середовища розробки. Перше — щоб можна було здобути результат швидко, а потім також швидко його доробляти. Друге — щоб було легко поділитися з друзяками. Реально на цей час є тільки один вибір…

Це JavaScript! Причому HTML/CSS я б залишив “на фоні”. На JavaScript можна писати чудові ігри та додатки, які легко перестрибнуть на мобільні пристрої. Для того, щоб ними поділитись, не треба заводити акаунт розробника, та треба нічого встановлювати. До того ж JavaScript працюватиме як на айфоні, так і на андроїді, як на macOS, так і на Windows, тож ніхто не буде обділений. Це прям дуже важливо.

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

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

На таких засадах рекомендую PixiJS. Він як раз підходить під ці вимоги. Можна в одному файлі накрутити просту сцену, а потім потроху доробляти. Середовище розробки може складатися з одного HTML файлу та браузера. Тільки подивіться на цей посібник — саме такий підхід я й мав на увазі.

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

Окрема порада — вивчати англійську мову. Зараз діти краще розуміють, що це потрібно. Бо дійсно, без англійської вибір технології звужується до неможливого. Я не уявляю, що навіть порекомендувати. Тож все одно доведеться потроху розбиратися в документації англійською (в мої часи це була довідка по Borland Pascal.)

11.10.2023

Гарна тема — запорука вдалої доповіді

У світі публічних промов TED займають особливе місце. Я не раз чув, як на них рівняються та аналізують, як себе поводять ведучі — міміку, жести, та інше. Втім слоганом TED є “Ідеї, які варто поширювати.” Та, я думаю, з TED краще перейняти не манеру викладання, а в першу чергу здатність обрати влучну тему.

За моїм досвідом, саме гарна тема є запорукою вдалої доповіді. Та навпаки — з поганою темою мало що зробиш хорошою грою. Навіть не тому, що “треба бути професіоналом”, а просто тому, що тоді доповідь втрачає свою базову цінність. Було декілька разів, коли я спочатку погоджувався виступати, а потім вже шукав тему. Виходить кисло.

Тема доповіді має бути така, щоб тобі було цікаво її розповідати. Якщо хочеться робити доповіді — варто спочатку відшукати таку тему. Вона не обовʼязково має бути революційною — більшість доповідей такими не є. Головне, щоб тобі було цікаво. Далі залишається знайти підхожу аудиторію (тобто переходити до моїх попередніх міркувань).

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

10.10.2023

Чому деякі відповіді HTTP в Ruby отримують кодування ASCII-8BIT, а інші — ні

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

Як я писав в минулому, наразі ми майже завжди маємо справу з кодуванням UTF-8, тому важко помітити, що існують інші — принаймні, якщо ми не працюємо з двійковими даними. Так, зазвичай запит Net::HTTP.get() повертає рядок в UTF-8. Оскільки типова вебсторінка має саме це кодування (я навіть не зміг знайти протилежний приклад), то можна подумати, що звідти воно й береться. Але ні — насправді просто береться кодування за замовчуванням в Ruby.

Тому що Ruby взагалі не інтерпретує кодування, яке зазначене в відповіді HTTP. Цього не роблять тому, що інтерпретація не завжди однозначна. Ось обговорення. Є спеціальна опція response_body_encoding, яка або вказує кодування явно, або просить його все ж таки знайти з відповіді. (Або можна просто зробити .force_encoding результату, якщо вже знаєш, що туди передати.)

Звідки все ж таки тоді ASCII-8BIT? На це є точна відповідь. От звідси. А саме: якщо зміст відповіді передається стиснутим, тобто з Content-Encoding: gzip, то вмикається клас Inflater, який примусово перемикає результат в кодування ASCII-8BIT. Бо це є кодуванням для двійкових даних (те ж саме, що Encoding::BINARY.)

Мабуть, очікується, що саме двійкові дані будуть стиснуті? Але це навіть протилежно дійсності — бо найбільше користі від стискання текстів - HTML, CSS і так далі. Зображення, наприклад, самі по собі є стиснутими. А так виходить, що ми залежимо від налаштувань вебсервера, тобто .force_encoding все ж варто робити, принаймні для послідовності.

09.10.2023

Оновлення для Hacker News Feed

Сьогодні зробив два оновлення для своєї стрічки для Hacker News. Стрічка існує з минулого грудня та має своїх користувачів.

Перше оновлення дуже просте — тепер є коротша стрічка https://feeds.leonid.codes/hacker_news_lite.rss. Вона береться тільки з головної сторінки Hacker News та містить від 20 до 30 позицій.

Друге — отримав скарги на те, що стрічка місцями має зіпсоване кодування. Тут вийшло складно. Ну, тобто зрозуміти, що не так не дуже складно — код сторінки в Ruby отримує кодування ASCII-8BIT замість UTF-8, відповідно на виході зайвий раз перекодовується в UTF-8 та при цьому псує типографічні символи.

(Ці символи в оригіналі UTF-8 займають декілька байтів — наприклад em dash це 0xE2 0x80 0x94. Кодування ASCII-8BIT бачить ці байти як 3 різних символи, які поодинці конвертуються в 3 знаки UTF-8, які вже нічого не мають спільного з тире.)

Прямолінійний розвʼязок короткий — зробити документу .force_encoding('UTF-8') та й годі. Але ж мені треба зрозуміти, що є первопричиною. Зрозумів. Про це, мабуть, завтра, бо розʼяснення довге. Поки запрошую підписатись на стрічку Hacker News.

08.10.2023

Типи для представлення масивів даних в JavaScript

07.10.2023

Звідки росте дерево задач?

Як я писав, дерево задач - зручна форма для деталізації планів. За останні тижні переконався в цьому. Obsidian дає неперевершену можливість доповнювати задачі кроками та нотатками. Зокрема допомагає те, що можна винести задачу, яка розрослась, в окремий документ. Так можна зовсім не боятись записувати все, що спало на думку.

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

А так можна окреслити, хоча б приблизно, стратегічні цілі та погрупувати задачі по нім. Це відразу спрощує пріоритизацію. Задачі всередині мають схожу тему, та легше побачити порядок виконання. Цілей просто менше, та головне що взагалі зʼявляється можливість побачити їх та обрати наступну. Звісно, можна наробити більш ніж один рівень цілей, якщо це має сенс.

Наприклад: з 40 активних задач по робочому проєкту можна виділити: поточний епік (насправді, для нього я відразу зробив вкладене дерево); задачі по інфраструктурі; покращення процесів; відомі баги та недоліки. Тоді наступного разу, коли зʼявиться вільний час від роботи над епіком, я можу переглянути цей список, обрати, наприклад, що хочу витратити його на покращення процесів, та потім йти по списку конкретних покращень.

Якщо це очевидні речі, добре — бо на роботі є менеджмент. Тому й приклад я взяв знайомий. А в особистому житті рідко так саме ясно, за що хапатись — тут і допоможе стратегічне дерево.

06.10.2023

Використання Promise для побудови лінивих обчислень

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

Коли у вас уже є Promise, на ньому можна викликати .then() (та .catch()) скільки завгодно разів. Такі виклики призведуть до невідкладного виконання відповідного обробника. Після завершення поточного фрейму виконання, звісно, тобто семантика зберігається.

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

Можна звісно зробити менеджер стану (як Redux), а також механізм повідомлення про готовність. Може, використати EventEmitter та підписки.

Але як альтернатива до всього цього, можна зберігати сам Promise. Тобто результат виконання fetch(). При першому виклику робимо завантаження та зберігаємо Promise; а при наступних просто повертаємо той самий Promise. Споживачі нічого не знають про ці деталі реалізації, а просто отримують Promise з потрібними даними. В тому числі не буде проблеми, якщо другий виклик відбудеться до отримання результату, тобто Race Condition.

Так можна будувати й складніші ланцюги перетворень — я навів найпростіший приклад. Тобто проміжні результати виконання теж зберігати так само. Можна мати цілий граф, як в reselect, тільки асинхронно. Насправді коли про це згадав, то дійсно вся ідея схожа на reselect, та, можливо, може бути прямо там реалізована.

05.10.2023

Помилка тих, хто починає з AWS: не створити декількох акаунтів

Може, найбільш відома помилка у роботі з AWS - це коли зловмисники отримують доступ до ключів. Та і я про це вже писав. Ризики, повʼязані з ключами, можна значно знизити, якщо окрім головного акаунта мати також акаунт-пісочницю.

Ось неочевидна порада: акаунтів в AWS можна створити стільки, скільки вам потрібно — це нічого не коштує. Навіть є функція AWS Organizations, щоб поєднати всі акаунти під єдиним дахом платежів. Але її використання не обовʼязкове, можна просто декілька разів зареєструватись.

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

В пісочниці можна (та потрібно) розташувати стейджинг. З Terraform відтворити зменшену копію продакшна можна майже без зусиль. Тому можна навіть декілька стейджингів. Також робити всілякі експерименти. Тоді в продакшні навколо живих сервісів не будуть зʼявлятися тестові, з незрозумілим рівнем безпеки.

04.10.2023

Найбільша помилка тих, хто починає з AWS: власні витрати

Я вже писав про те, як легко в AWS спалити гроші. Проте не встиг розповісти, що можна робити, щоб запобігти цьому.

Коли робиш свій перший проєкт на AWS, майже напевно натрапиш на неочікувані витрати, які вас не збанкрутять, але неприємно здивують. Зайві $100 на місяць можуть зʼявитися практично з повітря.

Мій улюблений приклад: якщо “по уму” зробити безпечну мережу, де внутрішні ресурси сховані в приватну підмережу, то для доступу з цих ресурсів в інтернет доведеться також додати шлюз NAT. Здавалось би, це абстрактна сутність, така сама як підмережі. Але ні - NAT-шлюз коштує $30 на місяць. За ці гроші на fly.io вже можна захостити потужний додаток. І це тільки “фундамент наших витрат”, так би мовити.

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

Також можна налаштувати Cost Anomaly Detection - вона повідомляє про надзвичайні витрати за окремою категорією, а не загалом. Тому це кращий механізм для більших проєктів, де значного перебільшення бюджету раптово не відбудеться, проте 100 pounds is still 100 pounds. Cost Anomaly Detection точно не проґавить зайву копію СУБД, забуту зі стрес-тесту.

Завтра — про другу за важливістю помилку.

PS: також завтра я візьму участь в стрімі DOU про безпеку AWS тут. Запрошую долучитись!

03.10.2023

Робота з файлами безпосередньо в браузері

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

Раніше

Пізніше