Вас не вводит в когнитивный диссонанс браузер, который выжирает 3-4 гига памяти?! Это, на секундочку, столько, сколько хватает для работы среднего сайта, включая ОС, БД, веб-сервер и генерирующий код, например.
Так пусть бы и не ставили именно те апдейты, которые ломают систему. Но полностью отключать часть пользователей от апдейтов из-за того, что они купили новые компы — это жлобство высшей пробы! При том — это в системе, которая официально поддерживается и для которой не наступил EoL!
Типа, в микрософте такие — «А нам лень писать патчи для новых ядер — идите нахрен! И пофиг.»
Я даже не знаю, что делать, когда восьмёрку перестанут поддерживать. Видимо — прийдётся жевать кактус линукса, ибо 10ка — это за гранью приемлемого для меня.
8-ка на 7+ поколении процессоров Интел не получает поддержку из-за наличии буквально такой функции. Если пропатчить пару функций в памяти — все начинает опять работать.
Внезапный, не волнуйтесь. Вы знаете, например, что с определенного момента на 8-ке нельзя получить обновлений, если она стоит на машине с Intel 7-го поколения? Просто нельзя — и всё.
Правда… Есть один маленький патчик. Он подменяет пару вызовов библиотечных функций. После чего пропадает голубое окошко и апдейты становятся без дальнейших танцев с бубнами!
И это называется «вменяемые границы поддержки»? По моему это просто — наипалово типичное.
Спрашивать с разработчиков за то, что они сделали программу, которая удовлетворяет спецификациям и уложились в отведенные сроки — это уже как-то… за гранью!
А если хотите хороший костюм… э… хороший код — тогда и отдайте управление процессом разработки в руки программистов! Будет вам отличный продукт — без багов, удовлетворяющий каждого клиента, использующий новейшие разработки в области ПО — только очень дорого и медленно. Но вам-то хочется быстро, качественно, НЕДОРОГО?
На самом деле сама статья — это один огромный наброс. Не говоря уже о провокационном переводе заголовка. Как тут уже выше указывали, «Have Software Developers Given Up?» правильнее перевести как «Сдались ли разработчики ПО?». Т.е. сам неправильный перевод заголовка статьи — это уже наброс.
Но даже при корректном переводе статья не передаёт быть набросом. Так можно на самом деле раскритиковать любую профессию. Например — дворников.
Вот без напряга родил план статьи «Сдались ли дворники?» чисто на жизненных примерах:
— кушал в заведении — под столом была прилеплена жвачка;
— шел по улице — увидел переполненную мусорку, из которой вываливался мусор;
— выпал снег — не расчистили проезд к подъезду;
— шел по улице — навернулся на льду;
— огромные лужи перед работой;
— дым от сжигаемых осенних листьев не даёт нормально дышать;
— дома на мониторе неубранная пыль;
— в офисе прошел по вымытому полу — остались грязные следы!!!
Теперь осталось добавить пафоса, сверстать всё в одну статью и прикрепить заголовок — «Неужели дворники опустили руки?»
Вот не надо, пожалуйста, обобщенных понятий. Автор себя отпозиционировал как «Девелопера». Не как сисадмина. Не как техсуппорта. Не как девопса. Не как менеджера ИТ-компании. Как «Девелопера». Соответственно — и спрос с него, как с девелопера. Т.е. он как минимум должен понимать разницу между «девелопером» — сиречь «программистом» — и остальными звеньями цепочки.
Иначе в угаре обощений можно докатиться до того, что «Сгорел утюг? Так эта Ванятка из второго подъезда виноват — вечно он чё-то с компутерами мутит!».
Соответственно тогда и накал статьи… того — поутухнет. Потому что ВДРУГ окажется, что виноваты-то по большей части не девелоперы, а… см. https://habrahabr.ru/company/ua-hosting/blog/283022/#comment_8882704
А про ложное ощущение вины Ванятки из второго подъезда — это, пожалуйста, к бабкам у подъезда (при чем — не второго).
Вестимо, это должно заставлять ESET и Microsoft тестировать свои продукты на конфигурациях, которые составляют 0,0001% от их базы.
И обязательно — включать всё возможное установленное ПО всех версий во всех конфигурациях, все возможные варианты поврежденной системы (понятно — всех версий со всеми возможными повреждениями всего существующего ПО во всех возможных конфигурациях).
Если сертифицированная программа не удовлетворяет неким критериям качества — это почти ничего не говорит о качестве программы, а говорит лишь о низком качестве процесса сертификации, который не включает основные критерии качества.
Я тоже хочу жить в стране Программии! Где у программистов есть ровно столько времени, сколько нужно, что бы написать красивый, быстрый, логичный, рабочий код да еще и покрыть его юнит-тестами. И где за всё это программистам платят такую зарплату, что им хватает на всё, чего бы они не захотели.
Но, увы — я живу в реальном, жестоком мире, где у меня есть сроки и ТММ надо мной. Я стараюсь изо всех своих программерских сил, что бы у меня получался красивый, быстрый, читабельный и безбажный код. Но если не успеваю — пишу так, что бы код как минимум не глючил. Всё остальное — опции.
В противном случае я, конечно, могу писать код любой красоты и охрененности — но платить мне за это не будут. И как-то на горизонте не видеать миграционных агентов из страны Программляндии…
Еще раз — автор статьи позиционирует себя как девелопера. Т.е. он должен быть в курсе разницы между контентом и кодом, а так же между «девелоперы сдались» и «менеджеры закусили удила».
А если он не в курсе всего этого — значит он не имеет морального права наезжать на других девелоперов.
Да, я в курсе, что не нужно быть поваром, что бы оценить качество блюда.
Но я так же в курсе, что если тебе дали тухлые яйца и приказали приготовить омлет — то что ты с этим не делай, то получится говно. И да — при этом маркетинг может преподнести это как «изысканное исключительное кушанье для гурманов, сделанное из столетних яиц». Но это — уже маркетинг. По факту — это будет говённый омлет из протухших яиц.
Проблема еще круче. Как себя позиционирует автор статьи?
> Я разработчик программного обеспечения и я создаю баги и ошибки.
Ладно, вторую часть откинем и оставим на его совести. Но по первой части — он, вроде бы, разработчик. При этом в самой статье лажается и путает баги программы с:
— недостачей контента;
— проблемой инфраструктуры;
— своим низким скиллом, когда ему не хватает квалификации понять смысл диагностической ошибки;
— завышенными требованиями к free software;
— закидонами маркетологов, которые заставили сделать галочку неотключаемой;
— ошибками в стороннем ПО, а не в системе;
— проблемами с локальной конфигурацией;
— итд, итп
Так же он пытается оценить качество ПО В ЦЕЛОМ по своим локальным глюкам — т.е. очень вольно обращается с кванторами общности: «Если у меня ПО не работает — значит ПО плохое в принципе».
> — Про бэкенд. Из текста и из вашего комментария складывается впечатление, что бэкенд вторичен. На самом деле он «главнее», потому что в нем находится логика. Если на фронтенде нет проверок, а на бэкенде есть, проблем с данными не будет. А если на бэкенде нет проверок, а на фронтенде есть, то можно отправить неправильные данные вручную, без фронтенда. У вас в статье примерно то же самое, но акцент сделан не на том.
У вас какое-то неправильно понимание. С точностью до «наоборот»: бэкенд должен КАК МИНИМУМ повторять все проверки фронтенда. Часто авторы движков полагаются на фронтенд, ослабляя проверки на бэкенде. Именно об этом данный параграф.
> Про intval. Тут вы поправили, но intval тут роли не играет. «echo 0123» тоже выведет 83. Это документированное обозначение 8-ричных чисел, так же как 0x123 обозначение для 16-ричных. Такое же обозначение используется, например, и в C++, и в Java, и в JavaScript. Из текста же складывается впечатление, что это какая-то фишка PHP, сходная с багом.
Опять — у вас какое-то странное понимание. Я написал про ОСОБЕННОСТЬ работы с числами — что 0123 не равно 123. И всё. Остальное вы сами додумали.
> Числа с плавающей точкой — проблема PHP. «Я говорил конкретно про PHP — в нём эта проблема есть». Это что-то вроде «у меня ваша программа не работает — так электричества же нет, поэтому компьютер не включается — ну и что, я же в вашей программе работаю».
Отсутствие врождённой способности оперировать с числами фиксированной точности и необходимость использовать для этого сторонние библиотеки и/или подключаемые плагины — это конкретно проблема PHP и достаточно серьезная, если игра оперирует числами типа float — в частности, если сравнивает такие числа. Особенно остро эта проблема стоит, когда в MySQL поле объявлено как DECIMAL — т.е. с фиксированной точностью.
> В проблеме с разрядностью про разрядность ничего не сказано. Не сказано, что в большинстве случаев такая разрядность не нужна, особенно в проектах начинающих. Если бы я не знал причину, у меня бы сложилось впечатление, что это опять какой-то косяк PHP.
Я уже не понимаю — какую статью вы читали? Указано на разницу в количестве разрядов в primary-ключе MySQL и максимальным количеством разрядов в целом числе PHP.
Нужна такая разрядность или нет — очевидно, решать не вам. И не мне. И даже не новичку, который разбирается в чужом движке. Это решил за него автор — и вопрос, на который должен ответить новичок — соблюдает ли автор движка свои же соглашения и везде ли корректно оперирует с полной разрядностью идентификаторов.
Я обозначил проблему. А то, что работать с целыми числами за пределами PHP_INT_MAX можно только с использованием специальных библиотек (а не просто используя стандартные операторы) — это действительно косяк PHP.
> Там написано, что я с этой проблемой не сталкивался, я не сказал, что ее не существует. Вообще это был своего рода намек «Уважаемый автор, не расскажете ли вы, с какими именно задачами вы столкнулись, что там переводы строк это серьезная проблема. Я вот не сталкивался, вдруг понадобится, хоть буду знать».
Очевидно — я видел это в одном из движков, которые ковырял. И проблема была именно в ненормированности данных — часть многострочных строк выводилась в JS нормально, часть — нет. В результате в лучшем случае не работал JavaScript на странице, а в худшем — появлялся мусор или вообще открывалась уязвимость для внедрения своего скрипта, потому что разработчик «запамятовал», что вводимые данные от игрока могут быть и некорректными.
> У вас половина статьи о том, что это важно, но нет никаких примеров, которые бы эту проблему иллюстрировали. Пара неправильно отформатированных строк это не примеры, потому что непонятно, как они появились.
Вы читал начало статьи? А её окончание? По-моему — нет. Иначе было бы очевидно, что эта — одна из статей цикла. Дальше будет (наверное — через неделю. Не снялся recovery mode) еще теория, а потом пойдут сплошные примеры.
IMHO — данные внутри движка должны циркулировать в виде «что бы не стыдно было в базу положить». Т.е. со стандартизированной отбивкой строк (CR+LF или LF — кому что ближе. Главное — единообразно по всему движку и независимо от системы), без какого-либо HTML-форматирования (хочется форматирования? Используйте BBCode или аналоги!), естественно — без какого-либо PHP-кода под eval().
Еще очень полезно явно типизировать переменные. Если это целое — значит это именно integer 48, а не string '48'. Если логическая переменная — значит типа boolean true/false, а не integer 1/0 итд
Типа, в микрософте такие — «А нам лень писать патчи для новых ядер — идите нахрен! И пофиг.»
Я даже не знаю, что делать, когда восьмёрку перестанут поддерживать. Видимо — прийдётся жевать кактус линукса, ибо 10ка — это за гранью приемлемого для меня.
support.microsoft.com/en-us/help/4012982/the-processor-is-not-supported-together-with-the-windows-version-that
support.microsoft.com/en-us/help/4012982/the-processor-is-not-supported-together-with-the-windows-version-that
8-ка на 7+ поколении процессоров Интел не получает поддержку из-за наличии буквально такой функции. Если пропатчить пару функций в памяти — все начинает опять работать.
support.microsoft.com/en-us/help/4012982/the-processor-is-not-supported-together-with-the-windows-version-that
Ставьте 10ку — и не волнует.
Правда… Есть один маленький патчик. Он подменяет пару вызовов библиотечных функций. После чего пропадает голубое окошко и апдейты становятся без дальнейших танцев с бубнами!
И это называется «вменяемые границы поддержки»? По моему это просто — наипалово типичное.
А если хотите хороший костюм… э… хороший код — тогда и отдайте управление процессом разработки в руки программистов! Будет вам отличный продукт — без багов, удовлетворяющий каждого клиента, использующий новейшие разработки в области ПО — только очень дорого и медленно. Но вам-то хочется быстро, качественно, НЕДОРОГО?
Так что — к циклу do-while претензии есть?
Но даже при корректном переводе статья не передаёт быть набросом. Так можно на самом деле раскритиковать любую профессию. Например — дворников.
Вот без напряга родил план статьи «Сдались ли дворники?» чисто на жизненных примерах:
— кушал в заведении — под столом была прилеплена жвачка;
— шел по улице — увидел переполненную мусорку, из которой вываливался мусор;
— выпал снег — не расчистили проезд к подъезду;
— шел по улице — навернулся на льду;
— огромные лужи перед работой;
— дым от сжигаемых осенних листьев не даёт нормально дышать;
— дома на мониторе неубранная пыль;
— в офисе прошел по вымытому полу — остались грязные следы!!!
Теперь осталось добавить пафоса, сверстать всё в одну статью и прикрепить заголовок — «Неужели дворники опустили руки?»
Смешно? Вот и я о том же…
Иначе в угаре обощений можно докатиться до того, что «Сгорел утюг? Так эта Ванятка из второго подъезда виноват — вечно он чё-то с компутерами мутит!».
Соответственно тогда и накал статьи… того — поутухнет. Потому что ВДРУГ окажется, что виноваты-то по большей части не девелоперы, а… см. https://habrahabr.ru/company/ua-hosting/blog/283022/#comment_8882704
А про ложное ощущение вины Ванятки из второго подъезда — это, пожалуйста, к бабкам у подъезда (при чем — не второго).
И обязательно — включать всё возможное установленное ПО всех версий во всех конфигурациях, все возможные варианты поврежденной системы (понятно — всех версий со всеми возможными повреждениями всего существующего ПО во всех возможных конфигурациях).
Фигли — деньги-то есть?
Но, увы — я живу в реальном, жестоком мире, где у меня есть сроки и ТММ надо мной. Я стараюсь изо всех своих программерских сил, что бы у меня получался красивый, быстрый, читабельный и безбажный код. Но если не успеваю — пишу так, что бы код как минимум не глючил. Всё остальное — опции.
В противном случае я, конечно, могу писать код любой красоты и охрененности — но платить мне за это не будут. И как-то на горизонте не видеать миграционных агентов из страны Программляндии…
А если он не в курсе всего этого — значит он не имеет морального права наезжать на других девелоперов.
Да, я в курсе, что не нужно быть поваром, что бы оценить качество блюда.
Но я так же в курсе, что если тебе дали тухлые яйца и приказали приготовить омлет — то что ты с этим не делай, то получится говно. И да — при этом маркетинг может преподнести это как «изысканное исключительное кушанье для гурманов, сделанное из столетних яиц». Но это — уже маркетинг. По факту — это будет говённый омлет из протухших яиц.
> Я разработчик программного обеспечения и я создаю баги и ошибки.
Ладно, вторую часть откинем и оставим на его совести. Но по первой части — он, вроде бы, разработчик. При этом в самой статье лажается и путает баги программы с:
— недостачей контента;
— проблемой инфраструктуры;
— своим низким скиллом, когда ему не хватает квалификации понять смысл диагностической ошибки;
— завышенными требованиями к free software;
— закидонами маркетологов, которые заставили сделать галочку неотключаемой;
— ошибками в стороннем ПО, а не в системе;
— проблемами с локальной конфигурацией;
— итд, итп
Так же он пытается оценить качество ПО В ЦЕЛОМ по своим локальным глюкам — т.е. очень вольно обращается с кванторами общности: «Если у меня ПО не работает — значит ПО плохое в принципе».
В общем — типичнейший наброс на вентилятор.
У вас какое-то неправильно понимание. С точностью до «наоборот»: бэкенд должен КАК МИНИМУМ повторять все проверки фронтенда. Часто авторы движков полагаются на фронтенд, ослабляя проверки на бэкенде. Именно об этом данный параграф.
> Про intval. Тут вы поправили, но intval тут роли не играет. «echo 0123» тоже выведет 83. Это документированное обозначение 8-ричных чисел, так же как 0x123 обозначение для 16-ричных. Такое же обозначение используется, например, и в C++, и в Java, и в JavaScript. Из текста же складывается впечатление, что это какая-то фишка PHP, сходная с багом.
Опять — у вас какое-то странное понимание. Я написал про ОСОБЕННОСТЬ работы с числами — что 0123 не равно 123. И всё. Остальное вы сами додумали.
> Числа с плавающей точкой — проблема PHP. «Я говорил конкретно про PHP — в нём эта проблема есть». Это что-то вроде «у меня ваша программа не работает — так электричества же нет, поэтому компьютер не включается — ну и что, я же в вашей программе работаю».
Отсутствие врождённой способности оперировать с числами фиксированной точности и необходимость использовать для этого сторонние библиотеки и/или подключаемые плагины — это конкретно проблема PHP и достаточно серьезная, если игра оперирует числами типа float — в частности, если сравнивает такие числа. Особенно остро эта проблема стоит, когда в MySQL поле объявлено как DECIMAL — т.е. с фиксированной точностью.
> В проблеме с разрядностью про разрядность ничего не сказано. Не сказано, что в большинстве случаев такая разрядность не нужна, особенно в проектах начинающих. Если бы я не знал причину, у меня бы сложилось впечатление, что это опять какой-то косяк PHP.
Я уже не понимаю — какую статью вы читали? Указано на разницу в количестве разрядов в primary-ключе MySQL и максимальным количеством разрядов в целом числе PHP.
Нужна такая разрядность или нет — очевидно, решать не вам. И не мне. И даже не новичку, который разбирается в чужом движке. Это решил за него автор — и вопрос, на который должен ответить новичок — соблюдает ли автор движка свои же соглашения и везде ли корректно оперирует с полной разрядностью идентификаторов.
Я обозначил проблему. А то, что работать с целыми числами за пределами PHP_INT_MAX можно только с использованием специальных библиотек (а не просто используя стандартные операторы) — это действительно косяк PHP.
> Там написано, что я с этой проблемой не сталкивался, я не сказал, что ее не существует. Вообще это был своего рода намек «Уважаемый автор, не расскажете ли вы, с какими именно задачами вы столкнулись, что там переводы строк это серьезная проблема. Я вот не сталкивался, вдруг понадобится, хоть буду знать».
Очевидно — я видел это в одном из движков, которые ковырял. И проблема была именно в ненормированности данных — часть многострочных строк выводилась в JS нормально, часть — нет. В результате в лучшем случае не работал JavaScript на странице, а в худшем — появлялся мусор или вообще открывалась уязвимость для внедрения своего скрипта, потому что разработчик «запамятовал», что вводимые данные от игрока могут быть и некорректными.
> У вас половина статьи о том, что это важно, но нет никаких примеров, которые бы эту проблему иллюстрировали. Пара неправильно отформатированных строк это не примеры, потому что непонятно, как они появились.
Вы читал начало статьи? А её окончание? По-моему — нет. Иначе было бы очевидно, что эта — одна из статей цикла. Дальше будет (наверное — через неделю. Не снялся recovery mode) еще теория, а потом пойдут сплошные примеры.
IMHO — данные внутри движка должны циркулировать в виде «что бы не стыдно было в базу положить». Т.е. со стандартизированной отбивкой строк (CR+LF или LF — кому что ближе. Главное — единообразно по всему движку и независимо от системы), без какого-либо HTML-форматирования (хочется форматирования? Используйте BBCode или аналоги!), естественно — без какого-либо PHP-кода под eval().
Еще очень полезно явно типизировать переменные. Если это целое — значит это именно
integer 48, а неstring '48'. Если логическая переменная — значит типаboolean true/false, а неinteger 1/0итд