Тоже поставил плюс за старания, но я сомневаюсь, что это реально кто-то будет использовать. Как говорится "лекарство хуже болезни". Если честно, то я вообще очень скептически отношусь к современным попыткам сделать из php подобие джавы. У php много минусов, но все же, если ты хорошо знаешь подводные камни, то на данный момент, он остается самым практичным языком для веб разработки.
Это если вы придираетесь к словам. Ну а если серьезно, то конечно я могу делать выводы лишь из небольшого количества собственных наблюдений, иначе любому можно предъявить - "А вы точно со всеми общались, чтобы такое заявляють? А вот мой друг Вася не такой".
Я сам программист и можно сказать из разряда вайтишников, просто мне не нравится тот ореол, который создается вокруг этой специальности.
И знаете что, нас таких много — кто вдохновился, покорился разуму, положил диплом на полку и шагнул в IT-сферу, чтобы стать одной крови с этим необычным сообществом
Как еще можно понимать такие перлы? Большинство программистов, это обычные люди, только с завышенным ЧСВ, который создан нынешним культом айтишности и непомерно высокими зарплатами.
Насколько я понимаю, в теории антивирус может читать https даже без подмены сертификата, просто встраиваться в процесс браузера и хукать библиотечные вызовы, собственно как это и делает разное malware.
Я лично видел как даже изначально неплохие программисты, которые после повышения отстранялись от конкретных деталей работы системы и начинали мыслить и проектировать в шаблонах/диаграмках, через некоторое время доходили до абсурда. Намного печальнее ситуация с начинающими архитекторами начитавшимися Фаулера. После этого оказывается, что проект должен быть platform agnostic, который при необходимости можно легко перевести с Azure на AWS и поменять Mysql на MongoDb настройкой в конфиге. Чем меньше человек начинает разбираться в деталях, тем больше сложные вещи ему начинают казаться простыми, а невозможное возможным.
Так "настоящим архитекторам" вообще зашкварно разбираться в деталях, это ведь любая обезьяна программист может сделать, а "архитектор" должен должен быть выше этого - мыслить абстракциями и творить с помощью диаграмм, кружочков и стрелочек.
С микросервисами как с шардингом - в большинстве случаев нужно избегать любой ценой и внедрять только в местах, где других вариантов нет. А еще перестать читать Фаулера, Мартина и Бека, ибо они только портят программистов)
С безопасностью в ХР ничем не хуже, чем в более актуальных ОС. По крайней мере, я не вижу у себя каких-то отличий, на все ОС одинаково вирусы пролезть пытаются.
У нее была критическая уязвимость MS08-067, которую использовал Conficker, так что как только ты подключал установленную XP напрямую к интернету, то с большой вероятность можно было подцепить этого червя. И в метасплоите это был пожалуй самый используемый эксплойт, так что любой соседский "хакер" в локальной сети мог этим воспользоваться (проверено лично).
Но вообще XP до сих пор моя любимая операционка, возможно из-за ностальгии по детству)
Проблема не в кустарном примере, а в том, что TDD за исключением отдельных ситуаций, работает только в кустарных примерах. Я бы вам советовал более критично оценивать все эти *-Driven-Development и не слушать всяких "гуру" с очередными методологиями, которые решают все проблемы разработки. Аналогия с марафоном была для того, чтобы подчеркнуть абсурдность подобной аргументации в TDD.
Не хочу никак обидеть автора, но это очередная статья о "просветлении" и познании истинного смысла TDD начинающим разработчиком(в чем автор честно признается). По мне, практически все статьи с примерами TDD можно охарактеризовать так:
Сейчас я покажу вам как быстро пробежать марафон, но к сожалению бежать марафон очень долго, поэтому я покажу как быстро пробежать 100 метров, но поверьте, в этом нет никакой принципиальной разницы, просто бегите так же быстро остальные 42 километра и у вас все получится!
Стоит отметить, что в InnoDB при дефолтном уровне repeatable read, фантомные чтения никогда не возникают. Подобное поведение может возникнуть, только если в транзакции между обычными селектами(без блокировок) сделаеть update записей вслепую, тогда при последующем селекте ты можешь получить новые записи, которых не было в первоначальной выборке.
При развитых «софт-скиллз» можно было убедить, что "число" это вообще абстрактное понятие, которое нельзя никуда сохранить и вопрос является бессмысленным) Правда, про второй тур после этого можно забыть, если конечно интервьюер не является поклонником философии Платона.
Совершенно верно. Никаким "принципам" нельзя следовать бездумно, у любых принципов есть границы их применения, и всегда нужно учитывать конкретные нюансы.
Согласен, я об этом и говорил, что такие личности как Мартин и его адепты, пропагандируют оценку кода на соответствие каким-то надуманным принципам типа SOLID, в отрыве от контекста и задачи, которую он решает. К этому добавляются крики об обязательном 100% покрытии юнит тестами, которое приводит к необходимости реализаций абстракций для моков, там где они абсолютно не нужны. В итоге проекты серьезно страдают, только ради того, чтобы им не предъявили - "тут у вас нарушается принцип Single Responsibility, нужно разбить этот класс на 5 других а также использовать интерфейсы и DI".
Не все фреймворки монструозные, а к монструозным фреймворкам приводят не сами принципы, а требования и цели, на которые ориентируются их авторы.
В чем-то вы правы, часть монструозности фреймворком лежит в попытке реализации как можно большего объема функционала. Тут вопрос в самом концепте фреймворков.
При всем при этом, как здесь уже неоднократно замечали в комментариях, во многих случаях при отказе от фреймворков после определенного этапа в итоге в коде получается самодельная аналогичная, но гораздо более кривая и косая реализация чего-то похожего на какой-то из тех же фреймворков.
Не согласен, это стандартная страшилка для новичков - лучше сразу используй наш супер модный react,vue,angular и тп., иначе потом сам прийдеш к самописному фреймворку, только кривому. В этом есть доля правды, может ты и напишешь часть своего, но это будет только маленькая часть, которая решает конкретно твои задачи и не будешь никак зависеть от стороннего решения. Если нужно что-то изменить или оптимизировать, ты не должен городить костыли, править сторонний фрейворк и потом бояться обновлений. Тут все не так однозначно. Для всяких веб студий, которые клепают однотипные решения это ок, но брать фреймворк для собственного проекта глупо.
Угу. Но чтобы отказаться от расширяемости и тестируемости, вам нужно быть на сто процентов уверенным, в каком направлении и как будет развиваться проект через N, N*2, N*5 лет. Что тоже требует дара провидения.
В этом и состоит проблема, что никто не знает. Если ты не уверен, в каком направлении будет развиваться проект, то нужно действовать по обстоятельствам - добавлять функционал и рефакторить по мере изменения требований, а не лепить сходу горы абстракций, чтобы как говорят - "на будущее", "в дальнейшем было проще расширять". Не бывает идеальной архитектуры, которая магически расширяется и перестраивается под любые изменения требований, так что это больше вангование.
Вот "медленный" в этом ряду вообще выглядит странно. В случае с 95% известных паттернов, единственный оверхед, который они могут дать, это несколько дополнительных вызовов через vtable (в зависимости от языка еще могут быть дополнительные аллокации, но это уже проблемы этих языков).
Благодарю за развернутый ответ, но к сожалению вы и не угадали. Сильная неприязнь к этим принципам у меня появилась как раз после разработки достаточно крупных проектов. В самом начале, я так же читал и слушал всякие "умные" лекции о том как "правильно" писать код, про расширяемую архитектуру, модульность и тп. Это все хорошо звучит в теории, но на практике практически не работает (если у вас нет дара провидения). Попытка бездумно следовать принципам, приводит к текущим монструозным фреймворкам с сотнями классов и всякими AbstractProxyFactoryBuilderInterface. Привычка плодить горы классов и интерфейсов в угоду абстрактной расширяемости и тестируемости, приводит к тому что имеем - медленный, сложный и глючный софт. Не нужно решать проблему сферического коня в вакууме.
Вы правы, признаюсь, что лет 5 назад я окончательно перестал понимать, что такое SOLID и TDD и главное зачем это кому-то нужно кроме самого Роберта Мартина, который зарабатывает на этом деньги.
Мне кажется, что в сложившейся ситуации, немалую роль сыграла попытка следования всяким надуманным принципам типа SOLID,TDD,BDD и т.п, которые пропагандирует Боб Мартин и компания инфоцыган от программирования. В итоге вполне конкретные задачи, которые можно решить в несколько строчек кода, разрастаются в раковую опухоль, так как простое решение типа не соответствует "принципу".
Тоже поставил плюс за старания, но я сомневаюсь, что это реально кто-то будет использовать. Как говорится "лекарство хуже болезни". Если честно, то я вообще очень скептически отношусь к современным попыткам сделать из php подобие джавы. У php много минусов, но все же, если ты хорошо знаешь подводные камни, то на данный момент, он остается самым практичным языком для веб разработки.
Вы про Достоевского? :)
Это если вы придираетесь к словам. Ну а если серьезно, то конечно я могу делать выводы лишь из небольшого количества собственных наблюдений, иначе любому можно предъявить - "А вы точно со всеми общались, чтобы такое заявляють? А вот мой друг Вася не такой".
Я сам программист и можно сказать из разряда вайтишников, просто мне не нравится тот ореол, который создается вокруг этой специальности.
У меня создалось аналогичное впечатление.
Как еще можно понимать такие перлы? Большинство программистов, это обычные люди, только с завышенным ЧСВ, который создан нынешним культом айтишности и непомерно высокими зарплатами.
Может быть в старой версии Go не было метода Done или они про него не знали:) Но вообще, это одно и тоже.
Насколько я понимаю, в теории антивирус может читать https даже без подмены сертификата, просто встраиваться в процесс браузера и хукать библиотечные вызовы, собственно как это и делает разное malware.
Я лично видел как даже изначально неплохие программисты, которые после повышения отстранялись от конкретных деталей работы системы и начинали мыслить и проектировать в шаблонах/диаграмках, через некоторое время доходили до абсурда. Намного печальнее ситуация с начинающими архитекторами начитавшимися Фаулера. После этого оказывается, что проект должен быть platform agnostic, который при необходимости можно легко перевести с Azure на AWS и поменять Mysql на MongoDb настройкой в конфиге. Чем меньше человек начинает разбираться в деталях, тем больше сложные вещи ему начинают казаться простыми, а невозможное возможным.
Так "настоящим архитекторам" вообще зашкварно разбираться в деталях, это ведь любая
обезьянапрограммист может сделать, а "архитектор" должен должен быть выше этого - мыслить абстракциями и творить с помощью диаграмм, кружочков и стрелочек.С микросервисами как с шардингом - в большинстве случаев нужно избегать любой ценой и внедрять только в местах, где других вариантов нет. А еще перестать читать Фаулера, Мартина и Бека, ибо они только портят программистов)
У нее была критическая уязвимость MS08-067, которую использовал Conficker, так что как только ты подключал установленную XP напрямую к интернету, то с большой вероятность можно было подцепить этого червя. И в метасплоите это был пожалуй самый используемый эксплойт, так что любой соседский "хакер" в локальной сети мог этим воспользоваться (проверено лично).
Но вообще XP до сих пор моя любимая операционка, возможно из-за ностальгии по детству)
Проблема не в кустарном примере, а в том, что TDD за исключением отдельных ситуаций, работает только в кустарных примерах. Я бы вам советовал более критично оценивать все эти *-Driven-Development и не слушать всяких "гуру" с очередными методологиями, которые решают все проблемы разработки. Аналогия с марафоном была для того, чтобы подчеркнуть абсурдность подобной аргументации в TDD.
Практически полностью согласен со всеми тезисами автора статьи, прямо как будто сам писал)
Не хочу никак обидеть автора, но это очередная статья о "просветлении" и познании истинного смысла TDD начинающим разработчиком(в чем автор честно признается). По мне, практически все статьи с примерами TDD можно охарактеризовать так:
Сейчас я покажу вам как быстро пробежать марафон, но к сожалению бежать марафон очень долго, поэтому я покажу как быстро пробежать 100 метров, но поверьте, в этом нет никакой принципиальной разницы, просто бегите так же быстро остальные 42 километра и у вас все получится!
Стоит отметить, что в InnoDB при дефолтном уровне repeatable read, фантомные чтения никогда не возникают. Подобное поведение может возникнуть, только если в транзакции между обычными селектами(без блокировок) сделаеть update записей вслепую, тогда при последующем селекте ты можешь получить новые записи, которых не было в первоначальной выборке.
При развитых «софт-скиллз» можно было убедить, что "число" это вообще абстрактное понятие, которое нельзя никуда сохранить и вопрос является бессмысленным) Правда, про второй тур после этого можно забыть, если конечно интервьюер не является поклонником философии Платона.
Согласен, я об этом и говорил, что такие личности как Мартин и его адепты, пропагандируют оценку кода на соответствие каким-то надуманным принципам типа SOLID, в отрыве от контекста и задачи, которую он решает. К этому добавляются крики об обязательном 100% покрытии юнит тестами, которое приводит к необходимости реализаций абстракций для моков, там где они абсолютно не нужны. В итоге проекты серьезно страдают, только ради того, чтобы им не предъявили - "тут у вас нарушается принцип Single Responsibility, нужно разбить этот класс на 5 других а также использовать интерфейсы и DI".
В чем-то вы правы, часть монструозности фреймворком лежит в попытке реализации как можно большего объема функционала. Тут вопрос в самом концепте фреймворков.
Не согласен, это стандартная страшилка для новичков - лучше сразу используй наш супер модный react,vue,angular и тп., иначе потом сам прийдеш к самописному фреймворку, только кривому. В этом есть доля правды, может ты и напишешь часть своего, но это будет только маленькая часть, которая решает конкретно твои задачи и не будешь никак зависеть от стороннего решения. Если нужно что-то изменить или оптимизировать, ты не должен городить костыли, править сторонний фрейворк и потом бояться обновлений. Тут все не так однозначно. Для всяких веб студий, которые клепают однотипные решения это ок, но брать фреймворк для собственного проекта глупо.
В этом и состоит проблема, что никто не знает. Если ты не уверен, в каком направлении будет развиваться проект, то нужно действовать по обстоятельствам - добавлять функционал и рефакторить по мере изменения требований, а не лепить сходу горы абстракций, чтобы как говорят - "на будущее", "в дальнейшем было проще расширять". Не бывает идеальной архитектуры, которая магически расширяется и перестраивается под любые изменения требований, так что это больше вангование.
Напомнило шутки про "zero cost abstractions" :)
Благодарю за развернутый ответ, но к сожалению вы и не угадали. Сильная неприязнь к этим принципам у меня появилась как раз после разработки достаточно крупных проектов. В самом начале, я так же читал и слушал всякие "умные" лекции о том как "правильно" писать код, про расширяемую архитектуру, модульность и тп. Это все хорошо звучит в теории, но на практике практически не работает (если у вас нет дара провидения). Попытка бездумно следовать принципам, приводит к текущим монструозным фреймворкам с сотнями классов и всякими AbstractProxyFactoryBuilderInterface. Привычка плодить горы классов и интерфейсов в угоду абстрактной расширяемости и тестируемости, приводит к тому что имеем - медленный, сложный и глючный софт. Не нужно решать проблему сферического коня в вакууме.
Вы правы, признаюсь, что лет 5 назад я окончательно перестал понимать, что такое SOLID и TDD и главное зачем это кому-то нужно кроме самого Роберта Мартина, который зарабатывает на этом деньги.
Мне кажется, что в сложившейся ситуации, немалую роль сыграла попытка следования всяким надуманным принципам типа SOLID,TDD,BDD и т.п, которые пропагандирует Боб Мартин и компания инфоцыган от программирования. В итоге вполне конкретные задачи, которые можно решить в несколько строчек кода, разрастаются в раковую опухоль, так как простое решение типа не соответствует "принципу".
Это задача вычисления группы Галуа для конкретного уравнения. Насколько мне известно, для нее до сих пор не существует единого алгоритма.