Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
SDE в ЗСУ
  • Що нового чекаєте в iOS 17?

    Головне, щоб це оновлення не добило більш старі моделі як це все було з попередніми релізами, коли моделі 2-3 річної давності починають помітно підгальмовувати, що зроблено штучно і штовхає на оновлення до найновішої моделі.

  • Цифровізація війська. Досвід України — приклад для всього Заходу

    Це все піар. В управлінні (ядрі) до діджиталізації ще дуже далеко.
    Немає єдиної бази всіх військовослужбовців.
    Переміщення з посади на посаду (особливо між різними родами військ) — це окремі пекельні борошна, можуть займати 2-3 місяці (О — оперативність)

    За 2-3 дні збирається на обробку до 500 листів докуметів. Все передається із рук в руки. Включається фактор реальної пошти — яка їзде і передає інформацію через папір у 2022 (2023) році!

    СЕДО — система електронного документообігу — це чисто анекдот.
    Ви друкуєте документ (реєструєте в паперовому журналі, підписуєте) — далі скануєте — і потім відправляєте скан. На іншому боці його отримують, РОЗДРУКОВУЮТЬ, і далі опрацьовують. Можливо надсилають відповідь по такому же принципу.

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

    Звання — це бутафорія. Часто офіцери взагалі ніякі, а рядові — дуже кмітливі і досвідчені. Але є суворі правила, бо начебто офіцери — це великі фахівці. Контрактники частково некомпетентні.
    Система кар’єрного зросту побудована на стрибках, як правило в інші напрямки. І після кожного стрибку треба освоювати нові обов’язки (нормативну базу). Ті фахівці, які довго знаходяться на своїх посадах як правило дуже добре знають свою справу, але рости не можуть.
    Багато хто прийшов не за тим щоб робити щось корисне, а тому що тут можна було до війни сидіти і платили більше ніж мінімальна зп.

    Мав змогу спілкуватися з представником міністерства — доводив ці проблеми. У відповідь пролунало, що держава вже витрачала мільярди на діджитал системи і в результаті є якісь прототипи, які ледь працюють.

    Армії дуже треба фахівці. Бізнес аналітики, інженери і менеджери, але тупий устрій — це велике гальмо.

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

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

  • Кабмін змінив порядок військового обліку

  • Коли святкуємо День програміста? Обираємо дату

    Значить обійдемся тільки Пєніє. Талісман — то ж відповідально. А тут тільки бла-бла

  • Коли святкуємо День програміста? Обираємо дату

    тільки треба зробити україномовного Кожаєва
    ну і Пєніє — теж головний експерт

  • Коли святкуємо День програміста? Обираємо дату

    dou.ua/forums/topic/8
    Ось мабуть перший пост на форумі ДОУ від 10 липня 2008 року
    Це мала б бути визначна дата

  • Коли святкуємо День програміста? Обираємо дату

    День заснування ДОУ — це те що об’єднало всіх програмістів у велике ком’юніті. Нехай Макс чи Сергій уточнять дату

  • Які є конвенції в REST API та для чого їх дотримуватись

    Насправді є ще 4 стадія, коли пишуть свій стандарт

    І тут нижче вже згадували що ці стадії можна застосувати до будь чого.

    Наприклад використання бібліотек. Пригадаєм старий добрий jquery

    1. Спочатку новачки без знать наливного js щодуху використовували jq де треба і не треба, що породжувало інколи меми на стекоферфлоу з питанням як додати 2 числа у джейквері

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

    3. Наступним кроком стало розуміння коли бібліотеку всеж доречно використати, тому що знали її сильні та слабкі місця

    4. Ну і у випадку повного просвітління і виявлені критичної маси проблем — організовувалися ентузіасти або компанії які почали розвивати альтернативні бібліотеки, описувати документацію кращим способом і робити більш зручний API

    Але важливо не плутати 2 і 4 стадії. Дехто просто лінується вивчити апі і починає робити велосипеди, але всім нав’язувати що технологія Х гірша. Тому тут все дуже відносно

    А щодо статті, РЕСТ мабуть має право бути використаним. І в цьому немає нічого поганого. Краще хоч якийсь стандарт (порядок) аніж взагалі нічого

  • MySQL + PHP. Допоможіть вирішити проблему

    По інсертам, якщо можна розглянути балк інсерт — то це теж гарний імпрув

  • MySQL + PHP. Допоможіть вирішити проблему

    Це дуже погана ідея розміщувати так інфраструктуру. Ви розумієте скільки запитів до бд продукується під час одного реквесту? А ще те що кожен tcp пакет буде мати той пінг що ви сказали. Хоча мені не віриться що через пів світу у вас пінг всього 9мс.
    Швидкість світла 300000000 м/с відстань від штатів до Німеччини десь 12000км в метрах це 12000000 тобто сигнал в один бік фізично летить 0.04с і це тільки один пакет і в один бік. Ще стільки треба на повернення сигналу. А ще є затримки 1-2мс на кожному вузловому маршрутизаторі.
    Отже з фізикою і теорією трохи розібрались.
    Що можна зробити як адхок рішення:
    — Поставити кеш на запити. Редіс або мемкеш поруч з веб сервером
    — оптимізувати кількість запитів до мінімума. Робити агреговані запити замість окремих. Жадна загрузка
    — поставити веб сервер поруч з бд і ще один реверс проксі вже в штатах. Це буде найшвидший варіант. Так як оверхед спілкування з бд буде локальним, а пінг затратне тільки результат обробки реквеста

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

  • Зробимо $50К донейтів для «Повернись живим» на Patreon. Приєднуйтеся до флешмобу DOU

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

  • Повышение зарплаты(salary review)

    Додам від себе свій шлях підвищення за приблизно 10 років. Останніх декілька років пропущу, по відомим причинам

    Робота 1: (2000-3000) 1 рік
    Початок 2011 — зп 2000 грн (на той час десь 250уо)
    Через пів року підвищення за ініціативою роботодавця +500 грн (+25%) ~320$
    Через ще півроку ще одне підвищення на +500 грн (+20%) ~380$ — я через місяць змінив роботу

    Робота 2: (5000) 5 місяців
    Наступна робота 5000 грн (600$) — тобто перехід між роботами дав +2000 грн або +66% з 1 роком досвіду (хоча суми ті були смішні)

    Робота 3: (700-2500$) ~1.5 роки
    Пропрацювавши 5 місяців за 5000 — вигорів :) і перейшов за рекомендацією на 700$ чи 900$ (вже не памятаю)
    Потім перегляд через 3 місяці за ініціативою роботодавця до 900$ здається
    Ще один перегляд через 3 місяці — 1100$
    Ще один перегляд через 3 місяці пропонувалося 1300$ — я попросив 1500 — погодилися
    Ще один перегляд через 3 місяці пропонувалося 1700$ — я попросив 2000 — погодилися
    В цей час почалися затримки з виплатою зп
    Ще один перегляд через 3 місяці я попросив 2500 — погодилися, але по факту я так і не отримував їх через затримку, тому пішов звідти

    Робота 4: (2000-2200$) ~1.5 роки
    Я погодився на новий оффер за 2к, але то були стабільні виплат
    Через рік перегляд на 2200 +10% — це мені здалося замало. Я ще трошки попрацював і пішов далі

    Робота 5: (2700-4500$) — 4 роки
    При офері просив 2500$ — дали 2700
    Потім через декілька місяців мені накинули ще 200, виходило 2900
    Через 2-3 місяці у компаніі був щорічний перегляд для всіх працівників, мені накинули ще 100 і так я почав отримувати 3000$
    Через рік на перегляді я просто тупо сказав що хочу 3500 — і мені дали
    Через рік на перегляді я сказав що хочу +1000. Дали +800 — результат мав 4300
    Через рік на перегляді накинули +200 — результат 4500, це був майже потолок, особливо для PHP-dev, тому пішов шукати себе в іншому

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

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

    Зараз ринок щедрий і гарячий, тому з 2 роками досвіду можна просити 2-4к впевненно, звісно якщо є релевантні знання.

    Ну і ще один висновок — в перші роки можна легко подвоювати зп якщо до цього прагнути і уміти себе продавати в тій же самій, або іншій компанії через дорогу

  • Чому сервісна компанія — найкраще робоче середовище для більшості інженерів. Руйнуємо міфи про «галери»

  • Переоцінені можливості nil в Go або Nil is not nil

    Дуже важко читати. В прикладах немає місць на які треба звернути увагу.
    Було б непогано додати більше коментів по справі у приклади, або зробити якійсь хайлайти з текстом, на що саме треба звертати увагу.
    Буди компілятором упродовж читання статті не хочеться.
    За старання звісно подяка, але все дуже сухо, прямо як у ГоФів.

    Підтримали: Олег Талавер, Andrii S
  • «Достойный уровень зарплат — это гигиена». Владислав Чечеткин, основатель Rozetka — о зарплатах выше рынка, развитии ІТ-команды и о том, готов ли продать бизнес

    Працював над проектом на Yii1 і він ще досі працює (тисячі реквестів на секунду, БД на мільйони записів). Хоча здебільшого порізали на мікросервіси з голанг. Але там від фреймворку залишились тільки роутінг і орм. І доречі в них дуже приємний АPI, і все добре працює на останніх версіях пхп. Тому нічого цікавого. Там власного кода 99%, а фреймворк не має значення

    Підтримав: Sergey Grigoryev
  • [Relocation] Canada Vs Germany

    Мене цікавить питання про реальні кейси форсмажора у ельфії ?
    Бо про тут (в Україні) судячи по тезам зрозуміло (захворів раком — вважай що помер, проблеми з законом — рахуй що сидиш або компенсація у зворотньому напряму, корупція у чиновників — це правило а не виключення). Ми завжди ставим у противагу що там краще, але наскільки мені відомо, страхова шукає завжди привід для відмови у важких медичних випадках, поліція теж в <ватева лівс мате> буває не завжди корректною. Зброя та наркотики у підлітків перетворює ельфію на зони де живуть багаті і виховані та бідні і люмпенизовані.
    Так от, я дійсно хотів би зрозуміти наскільки і в яких випадках ельфія вирішує у едж-кейсах, для прикладу хочаб реальні кейси про те як часто людина виліковувалась від раку, чи за рахунок трансплантації і відсутності грошей на те все ?

    Підтримав: Andrew Frolov
  • Infrastructure as Code: базові принципи vs інструменти, що еволюціонують

    diamail.com.ua/book/9343.html

    Вже є. Але іншої книги
    www.amazon.com/...​rvers-Cloud/dp/1491924357
    Не має в перекладі. Я як раз Її Гуглив і натрапив на цю статтю

  • Универсальный vs узкопрофильный программист. Определяем путь

    Те що ви так відповіли ще раз підтверджує тезу про почуття ангулар девелопера версіЇ х.х.х :)

  • Make your life easier with Jenkins X

    Працюю з гітлаб CI. Кожна гілка проекту автоматом деплоїться в кубер в окремий неймспейс (превю енв). Описано це в пайплайні. Гадаю що в jenkinsX теж щось таке треба буде описати

  • Чому SOLID — важлива складова мислення програміста. Розбираємося на прикладах з кодом

    За статтю дякую, але є декілька але:
    1. Якщо я зарефакторю проект і буду там одночасно застосовувати всі ці підходи, то ревьювери зходять зрозуму коли мої коміти аффектять 50-100 файлів. Це змушує мене робити довгі ітерації і розбивати рефакторінг на маленькі коміти і чекати поки їх заапрувлять. Тому це камінь в бік код-ревью і тих ревюверів які не можуть осягнути сенс рефакторінгу. (Або питання, як в такому випадку проштовхнути рефакторінг не за пів року ?)
    2. По опен-клоз принципу, тут основна мета — backward compatibility. Завжди користуюся цим принципом і по суті воно перекриває мету даного принципу
    3. Задетектити фічу на перед і зробити оверінжинірінг із 10 інтерфейсів і 20 реалізацій — не завжди потрібно, тому тут треба всеж оцінювати ТЗ і/або його надавати у повному обсяці, а не видавати порціями після реалізації попередньої частини.
    4. Обожнюю рефакторити і давати коду друге життя, замість безглуздого переписування з 0 з тими же проблемами, тому не бачу проблеми згодом рефакторити деякі частини коду, які дійсно цього потребують в процессі розвитку проекта. Це економічно ефективніше ніж наперед придумувати і обробляти кейси які ніколи не будуть існувати насправді.
    5. Якось доводилося працювати з модулем в якому всі класи і методи були фіналізовані. Мабуть автори коду були фанатами теж деяких із цих принципів, тож забрали можливість використовувати поліморфізм і змусили мене не розширити модуль з кастомною реалізацією, а повністю написати свій модуль повторюючи функціонал існуючого на 90%. (Цей кейс вже не до вас, а просто на тему поста)

← Сtrl 123456...12 Ctrl →