і яке ці фільми мають значення до ідей і причин фемінізму?
Так Еді Мерфі про це вже знімав фільм Daddy Day Care
А-а-а, ну це — Авторітет!
Якщо в кіно показали, то так воно й воно і у житті, ага.
Шось у вас виводи неправильні.
Це не в мене.
Це наприклад у Клаудії Голдін, у її роботі що отримала нобелевьску премію по економиці. Голдін зібрала дані більш ніж за 200 років, щоб продемонструвати, як і чому змінилися гендерні відмінності у доходах та рівні зайнятості
Нормально заробляйте
Ну то жінки, заробляйте! :)
і наймайте клінінг і нянь, у чому проблема?
Коли у тебе дохід вище середнього — просто наймаєш няню, і не страдаєш.
чому — нянЮ, а не нанЯ? що за дискримінаційне упередження щодо жінок та чоловіків?
а у нянь — дохід як, теж вище середнього? Вони теж для своїх дітей — нянь наймають?
вона наймається на 8 годин в день, всі інші 16 годин мама з дитиною
Рилі? А де ж батько дитини у ці 16 годин? Зник? А у цієї мами дохід вище середнього?
А як же кар’єра мами, яка витрачає 16 годин на дитину, замість того щоб працювати, будувати кар’єру?
Просто чоловіки вирішили що вони можуть насолоджуватись життям
ну, статистика по людству якось каже інше.
чоловіків і гинуло завжди більше, і живуть менше. і т.д.
тобто оця фігня «чоловіки вирішили» якось не співпадає з дійсністю.
навіть по годинах проведених на роботі — це теж статистика.
якось дивно «чоловіки вирішили» насолоджуватись — вкалувати більше і частіше мерти
а жінка це безкоштовна домашня обслуга, зручно
так, згоден — треба крім «діти зло для жінки» ще додати — «не виходьте заміж — станете безкоштовною обслугою!»
і буде щастя людству ще більше.
жінка вимушено втрачає кар’єру заради дітей
Саме так.
Тому вихід простий — жінкам треба відмовитись від дітей, і все.
Про це постійно повинні говорити, — діти зло для жінки, і т.д.
І буде щастя людству.
Чи готові до певних змін.
та готові — айті бізнес потихеньку йде з України.
по водійках карів та тракторів, по шахтарках та охоронницях — готові.
аби самі жінки були готові опанувати вказані професії.
Наприклад — замість швачки, шкільного вчителя, касира/продавця.
Ще є — електрики, сантехники, автомеханіки і т.і. — хочуть туди йти жінки, чи їх хто не пускає?
маленьке щось умовно з однієї форми приймає JSON і може десь в Redis чи Dynamo DB сторить. ... Коротше їло воно в нас 8 G
Кейси звісно різні бувають. З вашого опису — в пам’яті одночасно знаходиться гігабайти стрінгів. І, аплікація на Джаві таку ж кількість стрінгів якось більш оптимально зберігає.
Ну, є така відома проблема у Ноди — штатні JSON.parse та JSON.stringify можуть почати тупити вже на десятках мегабайт.
Крім того G1 який в Java з7-ї версії значно кращий за Mark-Swіp який в Node усе ще.
Тут важливіше навіть не сам тип GC — а як відбувається виділення пам’яті у конкретній аплікації і інтерпретаторі, ВМ — наскільки довго живуть об’єкти, наскільки швидко виникає те «сміття».
потім прийшов інший і скзав усе пишемо на Spring і в іншій системі
І можливо був правий. У вашому конкретному випадку.
До чого тут проміси то взаглі
До того, що як система звертається до I/O — то для подальшої роботи їй треба отримати відповідь.
І як вона те буде чекати — чи в чесному треді, чи від евен лупа — вже не має значення.
Це синтаксичний цукор не більше
Та як хочете його називайте. Головне що це вирішення проблеми потреби у паралельності.
І у Джава коді замість аwait стояв би запуск треда. Але тред — більш оверхедна штука аніж евентлпуп.
А треба то зазвичай для коннекту до БД в бібліотеці доступу до БД.
Запит до БД робиться для отримання результату. БД не відповідає миттєво. Тому — треба або чекати у чесному однопотоку — як у PHP, або — паралетити по факту виконання коду.
Як ви те зробите — тредами, каналами, Vertxіксом чи евентлупом — вже не принципово. Тобто чесна параллельність чи «нечесна» асінхронщина — вирішує цю проблему.
A WebASM це байткод, тобто якщо зробити JIT так само — проблема паралельності зникає.
Так питання ж у тому — коли вона і чому виникає :) Запит до БД виконується — паралельно роботі системи, чи послідовно.
але деколи те саме по перформансу
от про це деколи і мова.
Деколи нам треба обробляти гігабайти стрінгів, які приходят у вигляді JSON.
Деколи нам треба перемножати матриці.
Деколи нам треба тримати в пам’яті величезні хешмапи.
А зазвичай — ми чекаємо на відповідь від I/O. І — не хочемо щоб вся система, весь наш код чекав ту відповідь. От для цього, зазвичай і треба паралельність — щоб не чекати.
А деколи так, нам треба завантажити всі наявні ресурси CPU. Тоді асінхронщина не допоможе.
Хоча в Ноді і для цього вже є штатні засоби, але оверхед при їх використанні може бути вищий, ніж у JVM. Треба дивитись на конкретний кейс.
І ще такі результати бувають
Як на мене більш цікаві результати на www.techempower.com/benchmarks
На зараз там
18 ditsmod [postgres] — typ njs
Ditsmod — новий TypeScript веб-фреймворк для Node.js
dou.ua/forums/topic/32553
В моїй практиці, Node також використовує суттєво більше пам’яті навіть за Java.
Нетипова у вас практика. Одна з переваг Ноди на беку роками і є — значно менше використання пам’яті ніж у JVM.
А ще є свіженьке від AWS
LLRT (Low Latency Runtime) is a lightweight JavaScript runtime, for AWS Lambda, It’s built in Rust, utilizing QuickJS as JavaScript engine,
github.com/awslabs/llrt
що лімітує можливість багатопоточності і розраралелювання
Що зазвичай треба для операцій I/O
Можете порахувати кількість await’ів у наведеному в топіку коді. В цих місцях і були б запуски у іншому треді або передача виконання у паралельный channel
То як можна покращити наведений код «багатопоточністю і розраралелюванням»?
Замовники так і взагалі не хочуть платити за бекенд і не бачать в тому сенсу виділяти людей які їм не показують мультфільми з UI які вони здатні зрозуміти.
Вакансій — фулстек Java/.NET + Angular/React хватає.
та й Python/PHP теж.
Якщо буде зроблена попередня компіляція з будь чого (TypeScript/D/Darth/Kotlin/Jancy) в WebASM то проблему можна буде вичерпати.
На чому не пиши — писати треба під середовище браузера. Як ти його знаєш — то пофік на чому писати. Як не знаєш — то WebASM тобі нічим не допоможе.
чи стане це підгрунтям для «фемінізації» саме розробницької діяльності
Враховуючи що роботи значно поменшало, джунів ніхто не бере, синьорам теж важко знайти, тільки мідлам більш-менш ОК — то незважаючи на стать — відповідь «як війти в айті?» — «ніяк».
як нижче написали — джуна, не кажучи про трейні, не будуть брати на місце мобілізованого мідла, синьора. а будуть шукати саме такого ж рівня. і стать жіноча=НЕ мобілізують — не буде заміною навичок і експертизи у розробці.
там же де й інших програмістів.
просто — описати як захоплючі перспективи, так і поточний стан: треба вкластися власним часом і т.д.
ну як частенько на фріланс біржах пишуть:
мега супер бупер проект готовий на 90%! треба трішки доробити.
передплати — НЕ буде, оплата тільки після отримання проектом прибутку!
розробникам в яких потенційно мільйонні профіти від equity?
Це неправда навіть для американьских стартапів. Колись читав велике дослідження десь на Форбсі — переважна більшість інженерів «першої команди» не отримує нічого, бо не «доживає» до успішного успіху стартапу, виходу його на біржу, і т.і. Вигоряння, зміна технологічного стеку, менеджменту при зростанні — призводять до звільнень, коли за власним бажанням, коли компанією.
Інколи — отримують невеликі пакети акцій чи якихось «цінних паперів», але ж — більшість стартапів після хайпу «2го року» зникають на 5 році, то ці цінні папери так і залишаються — «почесними грамотами».
Чи готові айтівці ризикувати
Готові, поки не ризикували ні разу.
чи є взагалі люди, які б вклалися в творче завдання заради престижу та перспективи бути першими в зростаючому глобальному стартапі
Є. Молоді, які ще не вляпувались в стартап на таких умовах: місяці вджобування заради долі в прибутку майбутнього «гугла» :)
Тобто нема людей з експертизою
Бувають звісно. Все буває...
Але та сама експертиза зазвичай заважає. Вона ж не тільки у програмуванні, а і в знанні якщо не з власного досвіду, то з досвіду знайомих що результатом буде — «досвід».
А у людини з експертизою він вже є. Якщо така і сидить з якихось причин без роботи, то швидше вибере опанування нової технології, розширення своїх знань, та потратить час на власний пет проєкт — щоб додати до свого портфоліо.
мігрувати на flutter ... отримати собі такий значущий запис в портфоліо.
У кого в портфоліо вже є flutter — то що йому додасть ще один рядок?
Так що треба шукати серед тих у кого ще нема. Тобто людей без експертизи у flutter
кастомер излагает таски предельно кратко
В основном так и есть. Как я резюмирую эту типичную картину:
хотелка бизнеса
1 строка
бизнес анализ этой хотелки
10 строк
ТЗ, спека
100 строк
Код реализации
1000 строк
...стук падающего тела, занавес
Если на этапе формирования требований к продукту ошибку в требованиях можно предотвратить и доработать за пару часов, то исправление во время разработки уже будет стоить примерно 10 часов. Если проморгать проблему и код ушел на тестирование, то ее исправление может затянуть на
(см слайд 2 slideplayer.com/slide/16557549 он от Barry Boehm из его Software Engineering Economics)
И становится реальною черный юмор проектного менеджмента:
90% работы занимает 90% времени. А оставишиеся 10% занимают — еще 90% времени.
ну мы соответственно достаем из широких штанин неубиваемый как нам казалось аргумент
Как писал один:
Сбор требований это совсем не как по лесу гулять, грибы собирать.
Это ловля кастомера, помещение его в подвал и допрос с пристрастием.
Толкова у вас компанія. Поетапні проектуваня і здача робіт відомі як ітеративна розробка, наприклад у RUP
Як могла в роботу взятися задача, де неясні кінцеві результати та критерії «done»?
Та дуже просто — «Кнопка Х повинна княпатись» от і весь done
Тому що «аджайл» забороняє — керування вимогами; та моделювання, проектування домену.
«Ваша програма не працює!» — от тоді починається з’совування — що саме не працює, а як повинно...
Ну і документацію — ніхто ж не любить писати, чи не так?
Хоча, як на мене, йде до моєї старої мрії, завдяки ШІ — документація, специфікації, будуть такою же невід’ємною частиною програмування як і код. Бо все більшу частину коду буде писати ШІ. По — документації, спекам, діаграмам. А без документування, проектування — і програміст не те пише.
а якщо серйозніше, то в нас 1 мільнон «піхоти» вже «задіяно», але в «ділі» тільки частина з них
звідки інфа про «1 мільйон»?
і чому ж в «ділі» тільки частина цього мільйону?
до речі, якщо читати те що пишуть з фронту — то так, випадкі коли ремонтників 50+ років кидають у бій як піхоту, і вони там і залишаються лежати, навіки, у тих посадках — не такі вже й поодинокі.
Як нещодавна в одному інтерв’ю розказував боєць штурмового підрозділу:
Типова ситуація така — ми штурмуємо, відбиваємо посадку, підходять і окопуюються піхотні підрозділи, ми відходимо, росіяни штурмують... і нам знову треба відбивати ту посадку. бо нашої піхоти там вже нема...
то якщо і є «1 мільйон голів», згідно спискам військових частин — ви впевнені що ефективно кидати його «у діло»?
а штурмові підрозділи — то як сіньори фулстеки, і по беку і по фронту, плюс з знанням девопсу.
То частина проблеми в якості управління наявним ресурсом, яка точно не відповідає «реаліям 21 сторічча»
реалія — це тип війни який є. у реалі. інфи про те який цей тип війни за ці роки достатньо.
а уяви про те якою вона повинна бути у 21 сторіччі, то такє. мрії, казочки, научпоп.
Вміння адекватно використовувати наявні ресурси, точно і вчасно — це й є «мізки».
про це і сказав. якщо точно і вчасно користуватись «мізками», адекватно використовувати наявні ресурси — то можна вп’ятьох написати проект за 1 місяць, який зазвичай пишеться десятками людей за 9 місяців.
Повинна бути настільною, для всіх.
треба тільки москалям те пояснити. щоб не посилали свою піхоту.
головна проблема — завжди — в мізках.
угу.
«якщо крепко подумати, то цей проект можна зробити за 1 місяць, а не за 9.
і не десятками програмістів плюс з десяток піемів, плюс пара десятків тестувальників, а — вп’ятьох!
Головне — Ідея, проблема в мізках!»
На вордпрессе не особо такое построишь.
вообще-то вордпресс дает штатные возможности управлять генерацией html на самом низком уровне. какую тему надо — такую и пиши.
и производительности?
кешируется в нем тоже — как глобально, так и фрагментарно.
чем использовать бесплатные плагины платформ для создания сайтов.
они разные, плагины платформы для создания сайтов. Есть что да, не дают доступа к низкому уровню.
Лучше заплатить больше (не особо больше) за правильный сайт
Поэтому лучше заплатить меньше писателям сайта, которые потратят деньги и время на решение стопицот раз решенных проблем, и выбрать платформу с необходимым для задачи возможностями. Выйдет и дешевле, и быстрее.
яка зникне разом з державою Україна.
Народ який ставить себе вище за Державу — не матимите ані держави, ані конституції.