Во второй части будет немного CSS, но в упрощенном виде. Дело в том, что в React-сообществе до сих пор нет единого «правильного» подхода к стилям.
Один из core-разработчик, работая над react-native решил использовать inline-стили, чтобы не возиться с написанием css-парсера на тот момент. Неожиданно этот «анти-паттерн» оказался достаточно популярным среди сообщества и сейчас эта идея получила широкое развитие.
Мне нравится идея, что стили компонента лежат рядом с ним, а не определяются глобально. Другое дело, что inline-стили не кешируются и работают медленнее, чем классы.
Для решения этой и многих других проблем со стилями я в своих проектах сейчас использую jss, но также много хорошего слышал про aphrodite.
Так как статья рассчитана в основном на новичков, то мне показалось, что лучше на этом этапе тему css опустить и написать потом отдельную статью, если будет много интереса к этой теме.
Верно. Различные lint плагины есть к Atom, WebStorm, TextMate. Для других популярных IDE и редакторов тоже должны быть плагины, но у меня пока есть опыт работы с этой тройкой.
Каждый плагин умеет что-то свое, но еще нет такого, который бы исправлял прямо все проблемы кода разом, да это и невозможно. Насколько мне известно, команда eslint сейчас работает над инструментами, которые бы частично решали эту проблему.
Линтер можно добавить как плагин к тому же Саблайму, например. Это ускорит процесс разработки в том плане, что не придётся исправлять то, на что будет ругаться eslint после сохранения всех изменений. Хотя, с другой стороны, если самому определять правила в .eslint.rc, то он, линтер то бишь, может и не понадобиться.
Два профессионала не сошлись в естимэйте. Это само по себе не редкость, и случается сплошь и рядом. Но ваш вывод «избегайте евреев» не характеризует вас как профессионала, а в данном конкретном случае скорее наоборот.
Вообще же профессионала, помимо глубоких технических знаний, отличают отсутствие эмоций по поводу легаси кода, устаревшего стека, наличия/отсутствия процессов/тестов/бизнес аналитиков/тестировщиков/документации. Профессионал работает с тем что есть, объясняет клиенту имеющиеся недостатки и проблемы в понятных клиенту терминах, и знает, где у него оканчивается компетенция.
Поэтому соглашусь, что 6 лет это немного. Для мемуаров точно маловато.
Фишинг без JS, конечно же, был бы невозможен.
Я, например, не знаю почему, но был бы невозможен.
з.ы. а что до исключения — это хорошо, но канал-то не единственный (да и есть другие поисковики. Хоть и сомнительно, что их юзает большая доля пользователей этого бразуера).
Надеюсь что автор просто забыл пометить пост как перевод) На всякий случай я напомню, что оригинал тут http://davidhemphill.com/blog/2016/09/06/presenters-in-laravel/
Предполагается, что у компании уже есть небольшая серверная и админ, раз мы обозначили штат в пару десятков человек :) Потому решил не считать все с нуля, а обдумать в разрезе решения конкретной задачи по 1С.
Про облако вы безусловно правы, там есть свои минусы. Но это тема отдельной публикации, да и без нас уже сказано много о недостатках облачной среды. Решил не повторяться и не уходить от темы, сфокусировавшись на масштабировании. Если говорить о надежности в целом, то и одного сервера недостаточно – стоит делать кластер в том или ином виде.
Вы оторваны от действительности.
Вашему серверу нужна стойка и серверная. В серверную еще 2 кондера, админ и 2 циски :))
Это «НЛО» соберет себе за 60-70 тысяч комп на i5 с дешевым рейдом и поставит его в угол. На 5-6 лет им хватит.
И почему вы ничего не сказали про потери когда нет интернета или с облаком что-то случилось?
ну вот зачем отдавать преимущество {} перед [] для доступа к строке? ничего оно путать не будет, в других языках ведь как-то не путаются. а вот разные скобки задолбаешься ставить.
UPD: А не, они еще не решили
Скрытый текст
On the opposite side, it was also suggested that array access and string offsets are so closely-related concepts that we should recommend using '[]' in both cases and disable the alternate '{}' syntax for string offsets !
So, as the subject is controversial and very tangential to the subject of this RFC, it will be left for a future RFC.
Изменение работы isset() в 7.0.6 резко охладило мой пыл обновляться. То что разработчики могут без лишнего шума в минорной версии могут решить всё сломать не греет душу. Я в целом за то чтобы убирать грязь из движка, но вот так вот, в минорных версиях, без настроек, без этапа депрекации – это опасно. Я ж не могу за весь composer.json отвечать.
Ну проколы бывают у всех. Это хотели сломать еще в 7.0.0 — что было бы естественным.
Обьяснение
It is unfortunate that this change had to happen in a patch release, rather than in PHP 7.0.0. It's my fault that I did not notice during the pre-release cycle that this previously relatively harmless bug completely breaks the null-coalesce operator in PHP 7. However, that's how things went, and at this point a fix was critical.
For reference, the way to fix any issues with this change is to make sure your __isset() or offsetExists() functions behave correctly. If this change causes issues with your code, it indicates that you already have a broken __isset/offsetExists implementation, but it's brokenness did not previously surface (one bug canceling another...)
А вообще согласен, даже patch версии нельзя бездумно или автоматически обновлять, хотя бы не почитав changelog. )
Можно предположить, что это сделано для обратной совместимости.
Код, который имеет такое поведение уже написан и просто так ломать его не принесет успеха новой версии языка.
Хотя с другой стороны, было бы не плохо кидать какой-то warning для такого кода, чтобы фиксили активнее.
Простите, какая обратная совместимость? Речь о функции с возвращаемым типом void, который только-только вводится. В старых проектах таких ситуаций в принципе быть не может. Логично выкидывать предупреждение, если кто-то пытается присвоить значение функции с типом void.
Один из core-разработчик, работая над react-native решил использовать inline-стили, чтобы не возиться с написанием css-парсера на тот момент. Неожиданно этот «анти-паттерн» оказался достаточно популярным среди сообщества и сейчас эта идея получила широкое развитие.
Мне нравится идея, что стили компонента лежат рядом с ним, а не определяются глобально. Другое дело, что inline-стили не кешируются и работают медленнее, чем классы.
Для решения этой и многих других проблем со стилями я в своих проектах сейчас использую jss, но также много хорошего слышал про aphrodite.
Так как статья рассчитана в основном на новичков, то мне показалось, что лучше на этом этапе тему css опустить и написать потом отдельную статью, если будет много интереса к этой теме.
Каждый плагин умеет что-то свое, но еще нет такого, который бы исправлял прямо все проблемы кода разом, да это и невозможно. Насколько мне известно, команда eslint сейчас работает над инструментами, которые бы частично решали эту проблему.
Вообще же профессионала, помимо глубоких технических знаний, отличают отсутствие эмоций по поводу легаси кода, устаревшего стека, наличия/отсутствия процессов/тестов/бизнес аналитиков/тестировщиков/документации. Профессионал работает с тем что есть, объясняет клиенту имеющиеся недостатки и проблемы в понятных клиенту терминах, и знает, где у него оканчивается компетенция.
Поэтому соглашусь, что 6 лет это немного. Для мемуаров точно маловато.
Я, например, не знаю почему, но был бы невозможен.
з.ы. а что до исключения — это хорошо, но канал-то не единственный (да и есть другие поисковики. Хоть и сомнительно, что их юзает большая доля пользователей этого бразуера).
Про облако вы безусловно правы, там есть свои минусы. Но это тема отдельной публикации, да и без нас уже сказано много о недостатках облачной среды. Решил не повторяться и не уходить от темы, сфокусировавшись на масштабировании. Если говорить о надежности в целом, то и одного сервера недостаточно – стоит делать кластер в том или ином виде.
Вашему серверу нужна стойка и серверная. В серверную еще 2 кондера, админ и 2 циски :))
Это «НЛО» соберет себе за 60-70 тысяч комп на i5 с дешевым рейдом и поставит его в угол. На 5-6 лет им хватит.
И почему вы ничего не сказали про потери когда нет интернета или с облаком что-то случилось?
Данный код некорректен.
ну вот зачем отдавать преимущество {} перед [] для доступа к строке? ничего оно путать не будет, в других языках ведь как-то не путаются. а вот разные скобки задолбаешься ставить.
UPD: А не, они еще не решили
On the opposite side, it was also suggested that array access and string offsets are so closely-related concepts that we should recommend using '[]' in both cases and disable the alternate '{}' syntax for string offsets !
So, as the subject is controversial and very tangential to the subject of this RFC, it will be left for a future RFC.
For reference, the way to fix any issues with this change is to make sure your __isset() or offsetExists() functions behave correctly. If this change causes issues with your code, it indicates that you already have a broken __isset/offsetExists implementation, but it's brokenness did not previously surface (one bug canceling another...)
А вообще согласен, даже patch версии нельзя бездумно или автоматически обновлять, хотя бы не почитав changelog. )
У авторов php шмаль явно лучше чем у меня.
Код, который имеет такое поведение уже написан и просто так ломать его не принесет успеха новой версии языка.
Хотя с другой стороны, было бы не плохо кидать какой-то warning для такого кода, чтобы фиксили активнее.