Никогда такого не было и вот опять. Гугл банил мое расширение в хромсторе без всяких предупреждений. Вместе с гуглопочтой, к которой привязаны все аккаунты. Ну так, на всякий случай. Было это году в 2012-2013.
Былинный труд, который очень хорошо вправляет мозги и содержит ответы на бОльшую часть вопросов при работе с юникодом. Автору и переводчику большой респект.
Логика была отделена от представления и может быть изменена и протестирована отдельно. Элементарная функция здесь для упрощения понимания материала. Так же не стоит забывать, что минусы так же перечислены в конце статьи и если они критичны, то не следует пользоваться предложеным способом.
Статья полезна, ибо описывает один из способов разработки. Расширение кругозора и другой взгляд еще никому не вредили. Пользоваться или нет - каждый решит сам.
JSDoc вполне себе достойная полумера для облегчения кодинга. Closure Compiler вроде даже умел на основе этих аннотаций делать статическую проверку. И зачем тогда эти лютейшие генерики и костыли?
Учитывая тот факт, что разработчики, в большинстве своем, это интеллектуальная элита общества и добавляя тот момент, что никто не хочет работать больше - не могут. Когда плюсы использования технологии очевидны - люди переходят на нее не задумываясь. В данном случае видимо есть что-то, что заставляет людей задуматься. Редукс - много кода, да. Но он решает проблему с ротацией команды на проекте. Все знают, как организован редуксовый стор, это паттрен. Как родили 10к мобиксовых сторов 10 команд, которые работали над проектом - никому не известно. Бизнесу нужна стабильность, а не хипстота, и сдается мне, что это и определяет перевес в сторону редукса в 7 раз.
Оффтоп. Мне всегда была интересна мотивация людей, которые пишут провокационные, неаргументированные комментарии, сливают карму, регают новые аккаунты, чтобы продолжить срач и, вероятно, прикидываются другими участниками разговора, чтобы подогреть дискуссию. Вам оно зачем? Гемора много, лулзов мало. Реально есть еще кто горит?-)
Если вам что-то запрещают - вы уже подчиняетесь чужой воле :)
В программировании знаний ради знаний не бывает. Любой опыт пригождается, особенно полученный в самом начале. Чем качественнее он будет - тем лучше.
В ситуации, когда хочется рулить бизнесом - нужно наверное отдать дело в руки профессионалов и сосредоточиться на решении бизнес-вопросов, например где взять денег на этих профессионалов :) Я к тому, что программирование это ремесло, его надо изучать, вникать, любить ну и вот это все. Просто так с пары кнопок может что-то и получится, но скорее всего совсем не то, чего ожидаешь.
Я самоучка, потратил на это дело около 20 лет и да, в начале было тяжело, но интересно. "Дядю" всегда рассматривал с позиции - этот чел меня учит да еще и денег сверху платит. И для меня это всегда работало ) Ну если запрещают - куда деваться.
Метание закончится, когда надоест тратить время. Возьмите любой инструмент, углубите знания в нем, реализуйте задуманное. Когда настанет время для следующего проекта - недостатки текущего инструмента будут очевидны, а накопленный опыт подскажет какой следующий инструмент выбрать, вот и все.
Спасибо за ваш комментарий, аггрегирует много полезных либ. От себя добавлю что plotly - та еще ботва, во всяком случае на фронте. Куча пуллреквестов с фиксами висят с табличкой СМЕРЖИМ, КОГДА ДАДИТЕ НАМ ДЕНЕГ, ну и в целом эти ребята очень меркантильные и неторопливые, не рекомендую. Документация полный трэш. Столкнулся с plotly потому, что на момент выбора bokeh прибывал в забвении.
В вашем коде связывание просиходит на уровне импортов, не в рантайме. Ну и если у вас есть соответствующая фабрика и соответствующий сервис с DI он становится более ПЕРЕМЕЩАЕМЫМ, не зависит от импортов и их путей вообще. Дело вкуса короче. По идее оно должно делать мир проще, по факту уничтожает навигацию по коду. Надо постоянно держать в голове идею о том, что где-то сверху есть что-то, что вонзило сюда аргументы.
Согласен. Бизнесу все равно как это сделано, если оно удовлетворяет требованиям. Поэтому зачастую проще использовать устаревшие технологии, которые с большей вероятностью будут работать у большинства пользователей. И как показывает практика этих устаревших технологий хватает с головой :)
Заголовок статьи надо переименовать в "Мои любимые вопросы о CSS для верстальщиков-экспертов с ответами." Тут реально надо просто иметь спеку в голове.
У нас в компании пытались внедрить Svelte как альтернативу React для менее скиловых разработчиков, которым лень вникать в React, его жизненный цикл и это все. По итогу оказалось что изучать новый шаблонный язык, способы объявления биндингов и вот это все ОРИГИНАЛЬНОЕ в несколько раз сложнее, чем использовать JSX с нативными функциями, а сложность приложений несоразмерно выше, чем сложность инструмента. Тоесть у непрофильных разработчиков (биоинженеров) изначально не было шансов на фронте. Мой вывод с тех пор - чем ближе к нативному инструменту - тем лучше; поэтому я выбрал React.
Angular тоже не плох, но с другой стороны. Нативного там маловато, но это классический энтерпрайз фреймворк, как .NET. И если ты нанимаешь на работу ангулярщика, ты с очень большой точностью можешь определить его скилл; стиль проекта жестко регламентируется фреймворком; винтики заменяются по щелчку пальцев; ЭНТЕРПРАЙЗ!11
Все остальное делает ставку на уменьшение количества кода и увеличение количества подкапотной магии, что кажется мне лично вредным движняком, потому что ведет большое количество начинающих разработчиков не по пути изучения языка и базовых технологий (JS, DOM, CSS) а по пути изучения свистелок и перделок.
Каждый раз, читая подобные статьи, я убеждаюсь в том, что человек пока еще не пробовал разбираться в сотнях тысяч строк чужого кода, где понятность и простота стОит куда больше чем сэкономленая строчка, прячущая магию под капотом. И именно поэтому ему кажется что вот тут это реализовано лучше, чем там. TypeScript не зло, а способ написать код так, чтобы при взгляде на него было 100% понятно что он делает, какими типами оперирует в этой конкретной строчке. Да, порог вхождения чуть выше, да генерики, но на дистанции оно окупается. Для небольших проектов сгодится любой фреймворк, но стоит ли тратить время на его изучение, когда можно взять более надежный инструмент?
Ну и да. В какой-то момент разница между фронтом и бэком начинает заключаться в том, что на фронте еще и надо сделать красиво :-D
Удачи автору в начинаниях, без этих метаний между технологиями видимо никак. Желаю, чтобы они закончились поскорее и усилия шли на реализацию задуманного, а не жонглирование фреймворками.
Никогда такого не было и вот опять. Гугл банил мое расширение в хромсторе без всяких предупреждений. Вместе с гуглопочтой, к которой привязаны все аккаунты. Ну так, на всякий случай. Было это году в 2012-2013.
35mm + 50mm прикрученые фронтовыми линзами навстречу через переходник с алиэкспресс за 50 центов:
Спичечная головка
Так же помогают наборы макро-колец.
Xactly!
https://developer.mozilla.org/en-US/docs/Web/API/AbortController
When abort() is called, the fetch() promise rejects with an "AbortError" DOMException.
Былинный труд, который очень хорошо вправляет мозги и содержит ответы на бОльшую часть вопросов при работе с юникодом. Автору и переводчику большой респект.
Логика была отделена от представления и может быть изменена и протестирована отдельно. Элементарная функция здесь для упрощения понимания материала. Так же не стоит забывать, что минусы так же перечислены в конце статьи и если они критичны, то не следует пользоваться предложеным способом.
Статья полезна, ибо описывает один из способов разработки. Расширение кругозора и другой взгляд еще никому не вредили. Пользоваться или нет - каждый решит сам.
Не хватает тега Python. Для себя уточнил возможности asyncio про который 100 раз слышал, но использовать не доводилось. Выглядит приятно и понятно.
Пользуюсь более 14 лет, разрабам респект!
JS Fullstack приложение будет проще и легковеснее.
Толи еще будет. Скоро и поддержку JSX добавят, ато шаблоны не нативно же! :)
JSDoc вполне себе достойная полумера для облегчения кодинга. Closure Compiler вроде даже умел на основе этих аннотаций делать статическую проверку. И зачем тогда эти лютейшие генерики и костыли?
Учитывая тот факт, что разработчики, в большинстве своем, это интеллектуальная элита общества и добавляя тот момент, что никто не хочет работать больше - не могут. Когда плюсы использования технологии очевидны - люди переходят на нее не задумываясь. В данном случае видимо есть что-то, что заставляет людей задуматься. Редукс - много кода, да. Но он решает проблему с ротацией команды на проекте. Все знают, как организован редуксовый стор, это паттрен. Как родили 10к мобиксовых сторов 10 команд, которые работали над проектом - никому не известно. Бизнесу нужна стабильность, а не хипстота, и сдается мне, что это и определяет перевес в сторону редукса в 7 раз.
Оффтоп. Мне всегда была интересна мотивация людей, которые пишут провокационные, неаргументированные комментарии, сливают карму, регают новые аккаунты, чтобы продолжить срач и, вероятно, прикидываются другими участниками разговора, чтобы подогреть дискуссию. Вам оно зачем? Гемора много, лулзов мало. Реально есть еще кто горит?-)
Реквестирую более приближенные к жизни примеры - аргументы для евента, асинхронные движения в евентах, etc.
Не забывайте делать пометку, что это ваше личное мнение и около 7 000 000 людей в неделю с ним не согласны.
Если вам что-то запрещают - вы уже подчиняетесь чужой воле :)
В программировании знаний ради знаний не бывает. Любой опыт пригождается, особенно полученный в самом начале. Чем качественнее он будет - тем лучше.
В ситуации, когда хочется рулить бизнесом - нужно наверное отдать дело в руки профессионалов и сосредоточиться на решении бизнес-вопросов, например где взять денег на этих профессионалов :) Я к тому, что программирование это ремесло, его надо изучать, вникать, любить ну и вот это все. Просто так с пары кнопок может что-то и получится, но скорее всего совсем не то, чего ожидаешь.
Я самоучка, потратил на это дело около 20 лет и да, в начале было тяжело, но интересно. "Дядю" всегда рассматривал с позиции - этот чел меня учит да еще и денег сверху платит. И для меня это всегда работало ) Ну если запрещают - куда деваться.
Метание закончится, когда надоест тратить время. Возьмите любой инструмент, углубите знания в нем, реализуйте задуманное. Когда настанет время для следующего проекта - недостатки текущего инструмента будут очевидны, а накопленный опыт подскажет какой следующий инструмент выбрать, вот и все.
Спасибо за ваш комментарий, аггрегирует много полезных либ. От себя добавлю что plotly - та еще ботва, во всяком случае на фронте. Куча пуллреквестов с фиксами висят с табличкой СМЕРЖИМ, КОГДА ДАДИТЕ НАМ ДЕНЕГ, ну и в целом эти ребята очень меркантильные и неторопливые, не рекомендую. Документация полный трэш. Столкнулся с plotly потому, что на момент выбора bokeh прибывал в забвении.
В вашем коде связывание просиходит на уровне импортов, не в рантайме. Ну и если у вас есть соответствующая фабрика и соответствующий сервис с DI он становится более ПЕРЕМЕЩАЕМЫМ, не зависит от импортов и их путей вообще. Дело вкуса короче. По идее оно должно делать мир проще, по факту уничтожает навигацию по коду. Надо постоянно держать в голове идею о том, что где-то сверху есть что-то, что вонзило сюда аргументы.
Тут вы конечно правы. Но не умерла еще поддержка такой штуки как https://jsdoc.app/ В пайчарме, во всяком случае, работает. В вебшторме тоже должно.
Согласен. Бизнесу все равно как это сделано, если оно удовлетворяет требованиям. Поэтому зачастую проще использовать устаревшие технологии, которые с большей вероятностью будут работать у большинства пользователей. И как показывает практика этих устаревших технологий хватает с головой :)
Заголовок статьи надо переименовать в "Мои любимые вопросы о CSS для верстальщиков-экспертов с ответами." Тут реально надо просто иметь спеку в голове.
Для общего развития - шикарная статья, спасибо.
У нас в компании пытались внедрить Svelte как альтернативу React для менее скиловых разработчиков, которым лень вникать в React, его жизненный цикл и это все. По итогу оказалось что изучать новый шаблонный язык, способы объявления биндингов и вот это все ОРИГИНАЛЬНОЕ в несколько раз сложнее, чем использовать JSX с нативными функциями, а сложность приложений несоразмерно выше, чем сложность инструмента. Тоесть у непрофильных разработчиков (биоинженеров) изначально не было шансов на фронте. Мой вывод с тех пор - чем ближе к нативному инструменту - тем лучше; поэтому я выбрал React.
Angular тоже не плох, но с другой стороны. Нативного там маловато, но это классический энтерпрайз фреймворк, как .NET. И если ты нанимаешь на работу ангулярщика, ты с очень большой точностью можешь определить его скилл; стиль проекта жестко регламентируется фреймворком; винтики заменяются по щелчку пальцев; ЭНТЕРПРАЙЗ!11
Все остальное делает ставку на уменьшение количества кода и увеличение количества подкапотной магии, что кажется мне лично вредным движняком, потому что ведет большое количество начинающих разработчиков не по пути изучения языка и базовых технологий (JS, DOM, CSS) а по пути изучения свистелок и перделок.
Каждый раз, читая подобные статьи, я убеждаюсь в том, что человек пока еще не пробовал разбираться в сотнях тысяч строк чужого кода, где понятность и простота стОит куда больше чем сэкономленая строчка, прячущая магию под капотом. И именно поэтому ему кажется что вот тут это реализовано лучше, чем там. TypeScript не зло, а способ написать код так, чтобы при взгляде на него было 100% понятно что он делает, какими типами оперирует в этой конкретной строчке. Да, порог вхождения чуть выше, да генерики, но на дистанции оно окупается. Для небольших проектов сгодится любой фреймворк, но стоит ли тратить время на его изучение, когда можно взять более надежный инструмент?
Ну и да. В какой-то момент разница между фронтом и бэком начинает заключаться в том, что на фронте еще и надо сделать красиво :-D
Удачи автору в начинаниях, без этих метаний между технологиями видимо никак. Желаю, чтобы они закончились поскорее и усилия шли на реализацию задуманного, а не жонглирование фреймворками.
Hidden text