С интересом прочитал приведенную статью. Не понял, правда, момента с чтением данных. Мол, каждый компонент может читать данные любого другого. Т.е. мы разделили приложение на кучу максимально изолированных компонентов, которые сообщениями-то между собой обмениваются через посредника, чтобы друг о друге не знать. А потом создают эвент с моделями пользователя и заказа, чтобы его мог обработать компонент нотификаций? Это так и должно быть?
Как пользователь скринридера могу сказать, что главное свойство описания в aria-label — его наличие. Очень важно понимать, какой элемент на странице кликабельный, и что он делает. А "современный" подход делать такие элементы через span с onClick и иконкой внутри не дает никакой информации об этом. Сам на предыдущем проекте расставлял role="button" и aria-label на каждой странице, над которой работал. А иначе даже поставленную задачу не сделать.
По поводу aria-label у nav, единственное место, где я такое заметил — m.vk.com. Там прям так и есть
Насколько необходимо каждый раз слышать "Основная" и "Дополнительная" перемещаясь по спискам на странице — дискуссионный вопрос. Здесь главное не пересолить. А вот на кнопках видеоплеера метки очень нужны.
Accessibility в вебе — это не сложно на самом деле. И семантические интерактивные элементы — важная его часть. Иначе получится postman. Который из-за отсутствия семантики почти не юзабелен. А вот тег footer, действительно, не принципиален.
Даже по вашей ссылке php занимает вполне хорошее место. А с учетом того, что он, в отличие от прочих ЯП, представлен только в одной области, так вообще отличное.
Наследие эпохи PHP ещё долго будут разгребать и какие-то улучшения там происходить ещё точно будут.
Новые проекты на нем все так же пишутся. В своей области он вполне популярен.
Нужны какие-то очень весткие мотивы, чтобы заманить их обратно.
Я считаю, что у php довольно пологая кривая обучения, плюс Очень хорошая инфраструктура в своей области. Часто слышу, что php разрабов проще найти / они меньше стоят, что немаловажно для компаний.
Так что доля php может глобально и снижается, особенно за счет узости его применения. Но жизнь на нем вполне есть. И профессионал, и новичок в ближайшие 10 лет без работы не останутся.
На рынке кроме фактора спроса на язык есть еще и предложение спецов, умеющих в него. И на php, imho, проще начинать. В т.ч. из-за кучи фриланса и простых инструментов на нем.
переучись ты на другой стек, это не так уж сложно, если голова работает правильно…
А чем backend на java принципиально лучше, чем на php?
У меня в команде работал чел, перешедший с C# на php. Говорил, что Doctrine получше чем EF. Да и работу новичку проще найти.
И будут за тобой стоять очереди эйчаров.
За толковыми php-шниками тоже очередь. Видимо, везде сейчас так.
На php куча админок, систем управления делается. В т.ч. и с нуля. Как-то в разработке онлайн банка участвовал. На почту постоянно идет поток предложений рассмотреть ту или иную вакансию. Так что с редкостью COBOL вы уж совсем мимо.
И сам php как язык, отягощенный обратной совместимостью с не самыми лучшими решениями, по сравнению с новыми ЯП может и не очень. Хотя и он неплохо развивается. Но вот удобных фреймворков и библиотек на нем написана масса. Так что в целом разрабатывать легко и приятно.
С точки зрения пользования со скринридером оценки комментариев до их текста удобнее, чем после. Т.к. ты можешь заранее увидеть его рейтинг и либо остановиться внимательнее, либо вообще пропустить.
Мне кажется в вопросе заселения цивилизацией местной галактики есть несколько спорных предположений:
Цивилизация стремится к неограниченной экспансии.
Во всех развитых странах уровень рождаемости последнее время снижается. Вплоть до отсутствия воспроизводства населения. Легко предположить, что в относительно скором времени все население земли перестанет расти. А в таком случае для чего нужна экспансия? Ресурсов земли должно хватить на всех. А сидеть в своем смартфоне куда проще и интереснее, чем бороздить бесконечные просторы.
Технологии развиваются неограниченно.
Последние столетия наука развивалась очень быстро и сильно поменяла нашу жизнь. И успевшим к этому привыкнуть кажется, что так будет продолжаться всегда. Но в плане физики все скорее наоборот. Значимые с точки зрения практического использования явления открывать все сложнее и сложнее. Да и космические технологии развиваются куда медленнее, чем ожидали фантасты середины 20 века. Что уж говорить о приближении скорости перемещения в пространстве хотя бы к скорости света, без чего сложно представить межзвездные перелеты.
Так что окукливание немногочисленного человечества в киберпространстве кажется пока более реальной перспективой, чем создание хотя бы межзвездной цивилизации.
С каждым следующим поиском работы все прохладнее отношусь к тестовым заданиям.
В большинстве мест меня прекрасно брали и без них, после чего мы долго и успешно сотрудничали.
Задание часто требует больше времени, чем ты ожидаешь. Все-таки не каждый день нужно заново настраивать проект со всеми зависимостями. Плюс мне как бекендеру дают интеграцию с какими-нибудь апи внешних сервисов. Т.е. ты параллельно должен еще разобраться и с ними.
Жестко выбешивает, когда запрещают пользоваться фреймворками. Алло, у меня даже в резюме в графе должность / роль стоит "%framework_name% developer". И откликаюсь я именно на те вакансии, где он и используется. Но нет, ребятам хочется проверить "мои общие подходы". После чего ты каждый раз изобретаешь тот же фреймворк заново. Привет пункту 2.
Твою работу часто оценивают по принципу нравится / не нравится. У разрабов "я бы сделал иначе" и "ты написал фигню" нередко означает одно и то же. А попробуй по общим формулировкам ТЗ понять, что они хотят увидеть, да еще и в велосипедном исполнении.
Ну, и в конце они на тебя еще и забивают. Я чуть ни 2 недели бегал за одним товарищем, чтоб получить хоть какую-то обратную связь по тестовому. Ок, я уже понял, что вы меня не берете. Но оцените хотя бы то, на что я потратил все свое свободное время за 2 дня. В итоге он мне еще и по ошибке прислал отзыв по другому кандидату…
Туда же можно отнести и задание тестового, когда решение по твоей кандидатуре уже есть / от него не зависит. В этом легко могу понять негодование автора исходной статьи. Когда ты кучу времени делаешь никому не нужную ерунду, а в итоге тебе отказывают по совершенно другим причинам — это вызывает яркие эмоции.
повышают покупательную способность широких слоев населения — что, в конечном счёте, повышает прибыль собственников.
При условии замкнутости системы. В противном случае прибыль повышается у собственников азиатских производителей, а американские выдавливаются с рынка, вслед за чем падает покупательная способность широких слоев американского населения.
В подобных статьях однако любят выпячивать роль конкретной личности, задвигая на задний план ту среду, в которой они жили.
То же решение уйти вникуда из большой стабильной компании не выглядит столь безрассудно, если принять во внимание, что они находились в самом центре быстроразвивающейся отрасли. Где вокруг, как грибы после дождя, возникали успешные стартапы. А за углом жил знакомый венчурный капиталист, готовый вложить пару миллионов долларов в технологии, над которыми они до этого работали несколько лет.
Есть. Поэтому там решили не строить АЭС, а подогнать плавучие реакторы и переработать энергосистему под них. Плюс там планируются крупные проекты по добыче полезных ископаемых. Так что электричество очень нужно, и окупаемость должна быть достигнута.
если верить статистикам, превосходил танки/самолеты/артилерия Германию
Если ссылаться на того же Исаева, то он вполне внятно объясняет, что из себя по факту представляют десятки тысяч советских танков и куда они делись. Вкратце абсолютное большинство из них были легкими малоэффективными в 41 году машинами. Плюс абсолютное большинство танкового парка было потеряно в первый месяц войны. Когда немцы имели подавляющее численное преимущество в приграничном сражении. И хоть как-то их останавливать можно было только постоянными танковыми контратаками со слабой подготовкой и поддержкой и тяжелейшими потерями.
Так что прямое численное сравнение самолетов / танков может сказать далеко не все. Опуская их качество и эффективность использования, важно вспомнить про фактор стратегической внезапности нападения. И проблема там не в том, что солдаты на границе не успели попрыгать в окопы. А в том, что их было в разы меньше наступающих немцев. А на направлениях главных ударов на порядок. И дальше катастрофа развивалась как снежный ком.
вообще без подготовки бросать людей, это я и называю "забросать мясом".
Можно сейчас выдвигать любые благие пожелания на этот счет. Но ни ядерного оружия, ни спутниковой разведки, ни реактивной авиации у РККА на тот момент не было. И принципиально лучшую подготовку форсирования Днепра в тех условиях обеспечить было нельзя. И можно, конечно, говорить, что в той ситуации "врага забросали мясом". А можно, напротив, сказать, что быстрым форсированием спасли ни одну сотню тысяч жизней. Т.к. пробить устоявшуюся оборону по реке — это совсем другие потери. Да и параллельный геноцид находившегося под оккупацией населения никто не отменял.
именно такие действия и называются "забросать мясом"
Можете называть, как вам угодно. Но по мне детальный анализ того, что случилось, зачем и почему, более продуктивен, чем громкие эпитеты.
Ну, и если даже смотреть на итоговое соотношение потерь за всю войну, то оно вполне сопоставимо с поправкой на катастрофическое ее начало и организационно-технологическое превосходство Германии. Так что методы ведения войны в тех условиях примерно схожи и потери — тоже.
В любом случае не вполне понял вашу мысль. Локальное описание может быть вообще любое. А Днепр был форсирован относительно быстро и успешно. Сравните, например, с целом годом боев под Ржевом.
Немцам тогда еще менее сладко приходилось. Быстро отступать, часто в беспорядке — это совсем не весело. А на западном берегу их еще и несколько котлов ждало.
даже в мыслях не имеют научиться чему-нибудь полезному
А что полезнее в тех условиях может быть умения хорошо пользоваться АК?
проклятые каписталисты их ограбили!
Вы так говорите, как будто Атлантического треугольника а потом и колонизации не было. Или вы думаете, что столетия разрушения итак слабых местных государственных институтов никак не влияет?
Как раз изучаю Haskell. Там каррирование используется в основном, чтобы частично примененную функцию потом передать в функцию высших порядков. Ну, и для того, чтобы в бесточечном стиле лишние аргументы не пробрасывать. Еще прикольно одну функцию частично применять к другой. Результирующий тип по началу кажется очень неожиданным.
Так же нужно следить за хостингами, доступностями, SSL сертификатами и пр.
Github pages очень удобен в этом плане.
Аналогично с релизами. В случае с десктопом цена ошибки ниже. Если выявляется критическая бага, то пользователь просто будет пользоваться предыдущей версией.
В вебе релиз полностью под твоим контролем. Мне наоборот казалось, что это преимущество. Нашел багу — обновил сразу для всех. Нужно откатиться — для stateless сервиса это очень легко делается.
Но вообще ваше решение хорошо понятно и имеет безусловные плюсы. Особенно в контексте работы по флешке.
Может и можно через дженерики возвращать сущность из entityManager с не nullable id. Но при инжекте в контроллер с помощью ArgumentResolver уже придется прописывать дженерик вручную. Да и потом везде его по типам пропихивать. Так что трейт с getInitializedId с ассертом внутри кажется меньшей проблемой.
А ведь кроме id у сущности может быть куча автозаполняемых полей. CreatedAt updatedAt, createdBy… Часто они в doctrine event subscriber автоматом заполняются. Но тогда их тоже нужно делать nullable.
Я на одном небольшом проекте для себя успешно подружил Psalm с сущностями доктрины.
На моем текущем проекте у сущности может быть несколько десятков полей. Ну, пусть даже 10 из них не nullable. Как-то сомнительно их все через конструктор инициализировать. Да и формы с таким по дефолту не очень дружат. Не знаю насчет апи платформы и прочих библиотек..
Пехотные дивизии — да. Элитные танковые части, составляющие около 10% были полностью моторизованы. И именно они составляли основной элемент блицкрига. Т.к. танковая армия — это 150 — 200 тысяч человек, с танками, бронетранспортерами, моторизованной артиллерией, способных проходить по 100 км. в сутки. Именно они резали советскую оборону вначале войны. Пехота занимала территорию и добивала окруженные части.
С интересом прочитал приведенную статью. Не понял, правда, момента с чтением данных. Мол, каждый компонент может читать данные любого другого. Т.е. мы разделили приложение на кучу максимально изолированных компонентов, которые сообщениями-то между собой обмениваются через посредника, чтобы друг о друге не знать. А потом создают эвент с моделями пользователя и заказа, чтобы его мог обработать компонент нотификаций? Это так и должно быть?
Хорошая статья, спасибо.
Как пользователь скринридера могу сказать, что главное свойство описания в aria-label — его наличие. Очень важно понимать, какой элемент на странице кликабельный, и что он делает. А "современный" подход делать такие элементы через span с onClick и иконкой внутри не дает никакой информации об этом. Сам на предыдущем проекте расставлял role="button" и aria-label на каждой странице, над которой работал. А иначе даже поставленную задачу не сделать.
По поводу aria-label у nav, единственное место, где я такое заметил — m.vk.com. Там прям так и есть
Насколько необходимо каждый раз слышать "Основная" и "Дополнительная" перемещаясь по спискам на странице — дискуссионный вопрос. Здесь главное не пересолить. А вот на кнопках видеоплеера метки очень нужны.
Accessibility в вебе — это не сложно на самом деле. И семантические интерактивные элементы — важная его часть. Иначе получится postman. Который из-за отсутствия семантики почти не юзабелен. А вот тег footer, действительно, не принципиален.
Даже по вашей ссылке php занимает вполне хорошее место. А с учетом того, что он, в отличие от прочих ЯП, представлен только в одной области, так вообще отличное.
Новые проекты на нем все так же пишутся. В своей области он вполне популярен.
Я считаю, что у php довольно пологая кривая обучения, плюс Очень хорошая инфраструктура в своей области. Часто слышу, что php разрабов проще найти / они меньше стоят, что немаловажно для компаний.
Так что доля php может глобально и снижается, особенно за счет узости его применения. Но жизнь на нем вполне есть. И профессионал, и новичок в ближайшие 10 лет без работы не останутся.
На рынке кроме фактора спроса на язык есть еще и предложение спецов, умеющих в него. И на php, imho, проще начинать. В т.ч. из-за кучи фриланса и простых инструментов на нем.
А чем backend на java принципиально лучше, чем на php?
У меня в команде работал чел, перешедший с C# на php. Говорил, что Doctrine получше чем EF. Да и работу новичку проще найти.
За толковыми php-шниками тоже очередь. Видимо, везде сейчас так.
На php куча админок, систем управления делается. В т.ч. и с нуля. Как-то в разработке онлайн банка участвовал. На почту постоянно идет поток предложений рассмотреть ту или иную вакансию. Так что с редкостью COBOL вы уж совсем мимо.
И сам php как язык, отягощенный обратной совместимостью с не самыми лучшими решениями, по сравнению с новыми ЯП может и не очень. Хотя и он неплохо развивается. Но вот удобных фреймворков и библиотек на нем написана масса. Так что в целом разрабатывать легко и приятно.
С точки зрения пользования со скринридером оценки комментариев до их текста удобнее, чем после. Т.к. ты можешь заранее увидеть его рейтинг и либо остановиться внимательнее, либо вообще пропустить.
Мне кажется в вопросе заселения цивилизацией местной галактики есть несколько спорных предположений:
Цивилизация стремится к неограниченной экспансии.
Во всех развитых странах уровень рождаемости последнее время снижается. Вплоть до отсутствия воспроизводства населения. Легко предположить, что в относительно скором времени все население земли перестанет расти. А в таком случае для чего нужна экспансия? Ресурсов земли должно хватить на всех. А сидеть в своем смартфоне куда проще и интереснее, чем бороздить бесконечные просторы.
Технологии развиваются неограниченно.
Последние столетия наука развивалась очень быстро и сильно поменяла нашу жизнь. И успевшим к этому привыкнуть кажется, что так будет продолжаться всегда. Но в плане физики все скорее наоборот. Значимые с точки зрения практического использования явления открывать все сложнее и сложнее. Да и космические технологии развиваются куда медленнее, чем ожидали фантасты середины 20 века. Что уж говорить о приближении скорости перемещения в пространстве хотя бы к скорости света, без чего сложно представить межзвездные перелеты.
Так что окукливание немногочисленного человечества в киберпространстве кажется пока более реальной перспективой, чем создание хотя бы межзвездной цивилизации.
С каждым следующим поиском работы все прохладнее отношусь к тестовым заданиям.
Туда же можно отнести и задание тестового, когда решение по твоей кандидатуре уже есть / от него не зависит. В этом легко могу понять негодование автора исходной статьи. Когда ты кучу времени делаешь никому не нужную ерунду, а в итоге тебе отказывают по совершенно другим причинам — это вызывает яркие эмоции.
При условии замкнутости системы. В противном случае прибыль повышается у собственников азиатских производителей, а американские выдавливаются с рынка, вслед за чем падает покупательная способность широких слоев американского населения.
Было интересно, спасибо.
В подобных статьях однако любят выпячивать роль конкретной личности, задвигая на задний план ту среду, в которой они жили.
То же решение уйти вникуда из большой стабильной компании не выглядит столь безрассудно, если принять во внимание, что они находились в самом центре быстроразвивающейся отрасли. Где вокруг, как грибы после дождя, возникали успешные стартапы. А за углом жил знакомый венчурный капиталист, готовый вложить пару миллионов долларов в технологии, над которыми они до этого работали несколько лет.
Имхо подогнать парочку малых плавучих АЭС выглядит как-то реальнее. С дивана, как минимум.
Есть. Поэтому там решили не строить АЭС, а подогнать плавучие реакторы и переработать энергосистему под них. Плюс там планируются крупные проекты по добыче полезных ископаемых. Так что электричество очень нужно, и окупаемость должна быть достигнута.
Если ссылаться на того же Исаева, то он вполне внятно объясняет, что из себя по факту представляют десятки тысяч советских танков и куда они делись. Вкратце абсолютное большинство из них были легкими малоэффективными в 41 году машинами. Плюс абсолютное большинство танкового парка было потеряно в первый месяц войны. Когда немцы имели подавляющее численное преимущество в приграничном сражении. И хоть как-то их останавливать можно было только постоянными танковыми контратаками со слабой подготовкой и поддержкой и тяжелейшими потерями.
Так что прямое численное сравнение самолетов / танков может сказать далеко не все. Опуская их качество и эффективность использования, важно вспомнить про фактор стратегической внезапности нападения. И проблема там не в том, что солдаты на границе не успели попрыгать в окопы. А в том, что их было в разы меньше наступающих немцев. А на направлениях главных ударов на порядок. И дальше катастрофа развивалась как снежный ком.
Можно сейчас выдвигать любые благие пожелания на этот счет. Но ни ядерного оружия, ни спутниковой разведки, ни реактивной авиации у РККА на тот момент не было. И принципиально лучшую подготовку форсирования Днепра в тех условиях обеспечить было нельзя. И можно, конечно, говорить, что в той ситуации "врага забросали мясом". А можно, напротив, сказать, что быстрым форсированием спасли ни одну сотню тысяч жизней. Т.к. пробить устоявшуюся оборону по реке — это совсем другие потери. Да и параллельный геноцид находившегося под оккупацией населения никто не отменял.
Можете называть, как вам угодно. Но по мне детальный анализ того, что случилось, зачем и почему, более продуктивен, чем громкие эпитеты.
Ну, и если даже смотреть на итоговое соотношение потерь за всю войну, то оно вполне сопоставимо с поправкой на катастрофическое ее начало и организационно-технологическое превосходство Германии. Так что методы ведения войны в тех условиях примерно схожи и потери — тоже.
Что по официальным данным СССР?
В любом случае не вполне понял вашу мысль. Локальное описание может быть вообще любое. А Днепр был форсирован относительно быстро и успешно. Сравните, например, с целом годом боев под Ржевом.
Немцам тогда еще менее сладко приходилось. Быстро отступать, часто в беспорядке — это совсем не весело. А на западном берегу их еще и несколько котлов ждало.
А что полезнее в тех условиях может быть умения хорошо пользоваться АК?
Вы так говорите, как будто Атлантического треугольника а потом и колонизации не было. Или вы думаете, что столетия разрушения итак слабых местных государственных институтов никак не влияет?
Как раз изучаю Haskell. Там каррирование используется в основном, чтобы частично примененную функцию потом передать в функцию высших порядков. Ну, и для того, чтобы в бесточечном стиле лишние аргументы не пробрасывать. Еще прикольно одну функцию частично применять к другой. Результирующий тип по началу кажется очень неожиданным.
Github pages очень удобен в этом плане.
В вебе релиз полностью под твоим контролем. Мне наоборот казалось, что это преимущество. Нашел багу — обновил сразу для всех. Нужно откатиться — для stateless сервиса это очень легко делается.
Но вообще ваше решение хорошо понятно и имеет безусловные плюсы. Особенно в контексте работы по флешке.
Может и можно через дженерики возвращать сущность из entityManager с не nullable id. Но при инжекте в контроллер с помощью ArgumentResolver уже придется прописывать дженерик вручную. Да и потом везде его по типам пропихивать. Так что трейт с getInitializedId с ассертом внутри кажется меньшей проблемой.
А ведь кроме id у сущности может быть куча автозаполняемых полей. CreatedAt updatedAt, createdBy… Часто они в doctrine event subscriber автоматом заполняются. Но тогда их тоже нужно делать nullable.
На моем текущем проекте у сущности может быть несколько десятков полей. Ну, пусть даже 10 из них не nullable. Как-то сомнительно их все через конструктор инициализировать. Да и формы с таким по дефолту не очень дружат. Не знаю насчет апи платформы и прочих библиотек..
Пехотные дивизии — да. Элитные танковые части, составляющие около 10% были полностью моторизованы. И именно они составляли основной элемент блицкрига. Т.к. танковая армия — это 150 — 200 тысяч человек, с танками, бронетранспортерами, моторизованной артиллерией, способных проходить по 100 км. в сутки. Именно они резали советскую оборону вначале войны. Пехота занимала территорию и добивала окруженные части.