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

та сама історія і з середніми зарплатами — у мене в 2015 була нижче вказаної, а зараз вище, і що? так само як післязавтра може знов бути нижче. це ж не робить розрахунки не коректними. просто врахування інфляції робить цифри ближчими до реальності, ніж просто середні.

якщо ж рахувати у гривні, то отримуємо

2015: 2100 доларів це 47509 грн, з урахуванням інфляції в гривні це 112600 грн зараз.
2024: 3600 доларів це 147863 грн.

Тобто покращення є, але...

точно ні.

e-zubkovskiy.com/...​ulyator-inflyatsii-dolara

Девопс у 2015 отримував 2100, це дорівнює 2782 у 2024 з урахуванням інфляції, але зараз отримує 3600. Тобто майже половину підвищення «зʼїла» інфляція. Але все одно, дохід та купівельна спроможність зросли, це так.

Щодо доходів, було-б цікаво враховувати інфляцію. бо 4к у 2017 та 4к у 2024 — трошки не одне й те саме.

питання вкрай не вірно поставлене — куди мігрує людина залежить від її оточення — я можу 100500 раз хотіти переїхати у WhatsApp, але якщо всі друзі і контакти з оточення використовують Viber — то що толку з пустого WhatsApp?

А їх не існує, а існують тільки інтерпретації. Якщо це не фізика та хімія :)

ну, вибачте, тоді нам з вами немає про що сперечатись. Якщо фактів не існує...

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

І те і інше цілком можливо довести, наприклад, у суді. І платформа повинна прибирати джерела, які маніпулюють.

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

Бо яка притомна людина буде ганяти бухим посеред міста? Чи притомна людина буде підривати себе та інших на концерті заради віри в щось? Всі ж притомні — давайте не вживати заходів безпеки.

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

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

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

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

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

X для новин.

Той самий Х, який Маск придбав разом з проросійським саудітом та двома російськими олігархами... Логічно...

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

Так а на екрані що, значно більші? Там зручно було однією рукою і набирати і тримати девайс, зараз такі лопати...менше 6ʼ вже й не знайдеш нічого пристойного, нажаль. А ті, що з клавою — не зручні, що капець (я про бабушкофони). От форм-фактор blackberry, як на мене — найзручніше, що було. Принаймні, для робочого девайсу.

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

www.youtube.com/watch?v=Ckk4KbzJRVk
www.youtube.com/watch?v=juZMyAwvLMc

Це рекомендації від професійних військових.

В полях не завжди є можливість мити руки і піклуватись про лінзи та очі. Окуляри практичніше. Більшість нормальних тактичних окулярів має опцію вставки лінз. Вони також пластикові, тож, не бʼються. Я купив собі цілком нормальні за 2к грн + за 800 грн поставив лінзи під себе. Але в полях не тестив, використовував в якості вело окулярів — зручно.

Я не розумію, до чого це

Ну успіх *nix не скільки в якості як такої, я не думаю, що там значно краще ніж в середньому по проектах, скільки в зовнішніх факторах, таких як вільна (в достатніх рамках) ліцензія, гарна сумісність з зовнішніми системами, тощо. Хоча ще і архітектурно, що трошки не рівень коду, як такого.

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

Ну я ж не казав за всіх. Це моє особисте бачення.

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

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

Ось тут не погоджусь. Бо коли коду небагато, то дійсно, все здається очевидним (але не факт — регулярні вирази можуть виглядати «маленькими», а давати доволі непередбачувану поведінку)

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

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

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

Так до суті, є сенс досвідченому програмісту зараз читати щось про гарні практики чи просто достатньо не бути мудаком і писати як пишеться?

Особисто я вважаю, що знання за плечами не носити, та й вчитись ніколи не запізно ;)

наприклад використання войд пойнтера, я весь час чув шо так не можна

Я взагалі не люблю «абсолютних» правил. Тут (на мій погляд, знову ж таки) справа не в тому що «не можна» а в тому, що компілятор чи аналізатор коду не зможе спіймати помилку програміста, тобто вірогідність помилки росте.

Так само глобальні змінні,

Абсолютно те саме, вкрай складно контролювати коли саме і з якої частини коду може змінитися значення.

от з цим доречі в мене питання до вас, я інколи використовую не зрозумілі для середнього програміста(для нормального зрозумілі але зачасту вони не широкого вжитку) конструкції типу:
do {..} while (0);

Не вважаю себе експертом з програмування. Але як на мене — не бачу нічого не зрозумілого.

Массив вказівників на функції

Це доречі круто і зручно, але скажімо так, коли я сам з таким вперше зіштовхнувся то не зовсім зрозумів, та і інші теж носом крутили, а потім як зрозумів....

Ох, цілком вас розумію, я це побачив ще в університеті, як перейшов (просто заради цікавості) з pascal на С і там таке можна було робити — вкрай зручно, мені це тоді здавалось прям кіллер фічей ;D

Доречі про практики. Я, якось так сталося, пішов шляхом SysAdmin-DevOps і на якийсь час закинув С, а потім почав більше писати на Python (він для автоматизації ближче буде, ніж С) — але весь час дивився на інші мови — і мене якось дуже сподобався Rust, суто з інженерної точки зору, як там організована робота з памʼятю, вказівниками і ідея про те, що «небезпечний» код можна відокремити від «безпечного» — який доволі строго перевіряється ще при компіляції. Зараз переписую свої пет-проєкти (це всіляки автоматизації та боти для дому і повсякденних задач, невеличкі проєкти загалом) на Rust. Так до чого це я. Багато з перерахованих практик там так чи інакше реалізовані і «безпечні».

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

— алгоритмічну якість коду (умовно кажучі, краще використовувати О(1) ніж О(2) алгоритми, якщо можливо) — тобто, скільки ресурсів заліза потрібно для виконання коду і рішення задачі
— синтаксичну якість коду

До останньої якраз і відносяться всілякі «шаблони», ООП, процедурне чи функціональне програмування — і все це треба не компʼютеру, а перш за все нам, мавпам, для розуміння складного коду і спрощення його підтримки. Бо компілятор все одно що «спагетті», що розбитий по модулях і обʼєктах (чи функціях) код перетворить і оптимізує до невпізнанності (для нас, мавп). Питання виключно в тому, що розуміти, міняти та підтримувати «спагетті» значно важче нам. Так само і різниці між захардкоженими значеннями, константами чи дефайнами на рівні машинного коду ви вже не побачите. А ось підтримувати це — зовсім інша історія.

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

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

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

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

Тож, підсумовуючи (у порядку важливості, як на мій хлопській розум):

— намагайтесь використовувати найбільш оптимальні алгоритмічні рішення.
— намагайтесь дотримуватись загальноприйнятого для обраної мови стилю коду
— намагайтесь дотримуватись вимог до коду вашого проєкту.
— намагайтесь розділяти все, що може змінюватись (наприклад, конфігурація — адреси зовнішніх апі, адреси БД і таке інше) і те, що є константою для вашого проєкту, але змінює значення по-замовчуванню для сторонніх бібліотек — винесіть це в спеціальні файли конфігурації. (тобто уникайте хардкоду як такого), але, якщо ці значення «розкиданні» по кільком функціям чи файлам/модулям — інакше принципової різниці немає, достатньо винести в початок файлу, просто для зручності.
— уникайте використання будь-якого правила чи шаблону суто заради «щоб було» — наприклад, якщо зовнішнє АПІ використовується більше ніж в кількох різних модулях вашого проєкту — зробіть просту «обгортку», якщо ж це використовується виключно в 2 функціях у одному модулі, сенсу в цьому небагато. Як і написання узагальненого інтерфейсу для кількох можливих різних зовнішніх АПІ, якщо в природі існує лише одне.