Как стать автором
Обновить
25
0

Пользователь

Отправить сообщение
Согласен. Но сегодня и уже давно взламывают не только тех кто интересен, но и тех кто просто не волнуется. Цели взлома могут быть например создание ботнетов или майнинг или использование чужого сервера для атак на реальную организацию для заметвания следов и т.д.
За что люблю хабр — за то что аудитория вдумчивая и не ленивая. А можно саму статью покритиковать? Мне продолжение стоит писать?
Я подозреваю, там просто хабра эффект сработал. Товарищ весьма опрометчиво провоцирует исследователей, не подозревая пока о возможных последствиях.
Потому что личная жизнь каждого — это личная жизнь каждого. Кому-то будет не очень приятно стать «звездой» хабра. И я бы очень просил эту личную жизнь уважать. Это просто история как говорится «все персонажи выдуманы». Я думал вообще не упоминать никого, но тогда и писать особо будет нечего :-) Но ведь на самом деле вся жизнь и красота и разнообразие скрыто в маленьких нюансах, поэтому решил все же рассказать детально, но под вымышленными именами.
Ну вот не надо тут холиваров :-) говнокод в РНР — да, так сказать норма. Но если мы будем все же смотреть на те же фреймворки, они сделаны людьми с прямыми руками и для людей с прямыми руками. Просто РНР код всегда легко прочесть, он под рукой. Я уверен (по опыту) в других языках (той же Жаве) тоже полно говнокода в проектах, просто там все так построено, что код «соседа» редко читаешь, ну и таки да, порог входа для новичков значительно выше. Но профи они и на РНР профи, и обсуждение этой статьи это хорошо иллюстрирует.
Уважаемый, мне жаль вас огорчать, но вам надо просто еще многому учиться, учиться и еще раз учиться. Настоятельно рекомендую сделать 2-3 проекта в команде! чтобы были сроки сдачи и заказчик с дубиной за спиной. Ваши вопросы нестолько наивны и понятны, что я устал уже пытаться на них отвечать. Идите, пробуйте, читайте. Истина где-то рядом. Формат комментариев не подходит как системный инструмент для обучения, но похоже вы и об этом пока не догадываетесь. За сим дискуссию закрываю, вы уж меня извините.
Не надоело по пятому разу одно и тоже спрашивать? Нет, смысла мучаться нет. У меня есть дядя, он до сих пор считает что если программист не знает и не понимает ассемблер — то он не программист. Это просто другое измерение — хочется считать биты и байты — идите в Си и Ассемблер — там своя красота и свои лучшие практики. А если работаете на РНР, то извольте разобраться зачем его изобрели и как правильно и красиво писать на выбранном языке. Вся индустрия уже одной ногой в облаках, пока вы будете ковырять свой старый сервер, пытаясь выжать из него последнее, человечество улетит на Марс, а вы останетесь один на один со своим старым другом-серваком, на котором посыпется винт.
Проблема инклудов в современном РНР это то что оно не поддается кэшированию не уровне opcache который используется всегда, если руки растут из правильного места, я имею ввиду спагетти инклуды.
В общем, это долгая лекция. Попытаюсь еще раз объяснить. Теоретическая возможность сэкономить пару байт в памяти и пару тактов процессора на практике не выдерживает реальной конкуренции с ООП подходом по следующим причинам: скорость разработки, возможность независимой разработки модулей без потери их взаимосвязанности и взаимозаменяемости, возможность использования сторонних модулей и библиотек, простота работы в команде (где опытный разработчик уже знает как надо писать, а начинающий может легко найти документацию и best practices) так что мы снова экономим дорогое ВРЕМЯ, причем не только не разработку, но на обучение, тестирование, отладку, поиск источников проблем и т.д. Плюс как я уже говорил замена железа стоит дешевле и приносит мгновенные результаты, без необходимости заново тестировать всю систему в случае «оптимизации под память и проц»
Да, изменения в РНР коде не дадут почти никакого эффекта. Сегодня, и уже давно, купить железо в 2 раза сильнее стоит в 10 раз дешевле чем переписать код и приносит результат сразу и в разы, в том время как переписка/рефакторинг кода занимает кучу времени у кучи специалистов и приносит насколько процентов производительности.
Например если у вас сатрый комп который типа LAMP все в одном и у вас проблемы с проихводительностью, то купив два новых компа и разнеся РНР и MySQL на разные машины вы с высокой долей вероятности решите проблемы производительности за один день. Причем с доступностью облаков сегодня — это проверяется за пару часов в облаке за 2 бакса. Стоимость разработки это бич бизнеса сегодня. И еще раз — если вы будете переписывать ООП код в функциональный ради выигрыша в производительности в сложной системе, то во-первых вы с высокой степенью вероятности облажаетесь, а во вторых это будет стоить страшных денег в разы превосходящих замену железа.
Мне очень понравилась вводная часть. Я тоже сторонник сборки своего фреймыорка под проект. Но дальнейшая подача материала не стректурирована и не совсем понятно что и для чего мы делаем. Надеюсь, в скором времени накатать свой вариант статьи о сборке проекта из библиотек. Надеюсь у меня получится донести смысл такого подхода. Удачи!
Вот вы сами и «споткнулись» в рассуждениях. Да, пару байт или тактов процессора можно сэкономить без ООП. Но вот «зуб даю» что стабильнее будет работать ООП код :-) И если мы не говорим о чем-то маленьком или эмбедед и драйверах, а говорим об Приложениях или Application с достаточно сложной структурой, множеством модулей и взаимодействием и интеграцией с другими системами, то «спагетти-код» никогда не будет работать стабильно, вот просто никогда :-) (это конечно мое сугубо личное мнение)
А вы и автомобилями тоже не пользуетесь? Кто вам гарантирует что бензин будет завтра загораться от искры свечей так же как вчера?
Т.е. никто ничего не гарантирует, если меняются не фантики на фантики, а участвуют объекты реального мира.

Да никто не гарантирует что собеседник сможет выразить свою мысль так чтобы было понятно о чем он говорит. Людская лень, а данном случае написать пару лишних строк, она творит чудеса. Ваше бы предложение да на урок русского языка, чтобы мне учитель объяснил: где тут подлежащее, где сказуемое и где законченная мысль.
Не понимаю вопроса. Чья воля гарантирует что 2+2 завтра тоже будет равно 4? Чья воля гарантирует что завтра слово Компьютер не станет означать Трактор? о чем вы? это программирование, это алгоритмы. Мы (программисты как минимум) исходим из того что не нужна ничья воля чтобы 2+2=4 и чтобы яблоко падало вниз. Если для вас нужна чья то воля чтобы котнракт исполнялся, то для меня достаточно волеизъявления двух сторон. Попробуйте развернуть или переформулировать свой вопрос если вас не затруднит. Я искренне пытаюсь, но не могу понять что вы имеете в виду.
У вас странная логика. Вы используете аргументы говорящие в пользу блокчейна чтобы аргументировать против него :-) Давайте еще раз пройдемся по вашим аргументам.
Если кому-то не нравится сервис он может пользоваться альтернативным. Вы не видите разницы между опенсорс проектом без владельца и проприетарными проектами. Давайте я попробую дать вам понятный пример. Есть поисковый сервис гугл — он проприетарный и монопольный. Если я не согласен с там как он фильтрует и сортирует результаты поиска у меня нет альтернативы. Вернее она есть типа яндекс и бинг, но она меня не устраивает по ряду других причин. В мире опенсорса мы берем и форкаем, это относится не столько к блокчейну, но к опенсорс вообще. И делаю свой гугл и если я прав и мои идеи нравяеся пользователям мой сервис процветает а оригинальный гугл умирает. Но блокчейн вносит свою лепту тем что получившийся продукт не является «моим» он всегда общий! Никто им не владеет и никто не может его принудительно выключить или заблокировать как тот же гугл в Китае.
Второй ваш пункт насчет того что никто не читает соглашений. Я согласен, только вы путаете две вещи вместе. Соглашения которые вы подписываете сейчас это юридические игры. И мы все знаем что в суде нас всех легко отымеют все эти гиганты. А смартконтракты это суть сделки которую может понять каждый участник сделки: что продаем-покупаем, в каком количестве, почем. Это намного о другом. Да, сегодня уже есть примеры не очень грамотного исполнения смарт кортрактов. Но это все сейчас утрясается и в будущем мы будем им доверять больше. Это как «стандартный» договор купли-продажи. Любой человек который путался когда-нибудь что-то купить или продать пытался нагуглить хороший образец. Так вот рынок постепенно выведет все лучшие контракты в топ. И мы будем ими пользоваться не задумываясь, но зная что кто-то когда-то заплатил за «тестирование» этих контрактов своим удачным или неудачным опытом. Ошибки по пути неизбежны. Но суть остается — что написано пером, не может потеряться, не может «сгореть при пожаре», не может сбежать в другую юрисдикцию и т.д.
Далее насчет бана за смайлик, просто поверьте коммьюнити читает код. Если там будут мины из найдут — жто опенсорс. А закладки ЦРУ и ФСБ — мы не можем даже искать, у нас нет доступа к исходникам!
Фриланс.ру — отличный пример. Если бы они были созданы на блокчейне то что они сделали было бы невозможно. Если вы не видите преимущества «не случилось» перед «я это переживу» — это ваша позиция. Но подумайте чтобы вы предпочли на самом деле: чтобы дом не сгорел или чтобы у вас была страховка на этот случай? чтобы вы не сломали руку или чтобы вам поставили качественный протез? чтобы вы не потеряли работу или чтобы быстро нашли новую через пару мес и немного пониже зарплата? Я понимаю что это субъективно. Но я считаю что если какие-то проблемы можно просто избежать — то это преимущество.
Блокчейн — это не заклинание, это всего лишь технология. Меня не волнует электричество. Я его даже не замечаю. Но представляя себя на месте человека, который не понимает зачем ему дому лампочка, если у него есть 100 свечей 150 лет назад, а кто-то ему рассказывает о том что чтобы эта лампа горела надо еще и электростанцию построить, я точно понимаю что преимущества налицо.
Мы все пока еще не знаем где приживется блокчейн или квантовые компьютеры, но поверьте — приживутся. Сегодня в этом уже нет сомнений. :-) А обычный потребитель естесственно не будет думать почему одно лучше другого, но он точно будет знать что оно лучше ;-)
Пользователь выигрывает на прозрачности сервися. Не может кто-то взять и как гугл поднять кого-то в топ результатах поиска или вообще удалить поскольку приложение изначально децентрализованное. пользователь выигрывает на низких конкурентных ценах, поскольку открытость платформы позволяет получить доступ к неограниченному количеству поставщиков услуг а не через площадки и биржи которые делают вход в ту или иную отрасль довольно долгим и дорогим процессом. Почитайте вообще про преимущества блокчейн технологи, все уже объяснено и разжевано неоднократно.
Я правильно вас понимаю, по-вашему, ООП приводит к потере производительности по умолчанию? У меня очень другое определение для понятий ООП и архитектура. По-моему, когда архитектура правильная, например как у unix систем, то они работают стабильнее и быстрее по умолчанию в сравнении с системами у которых были допущены архитектурные ошибки, скажем windows. И вопрос для меня стоит не в «сложности архитектуры» а в самой Архитектуре как таковой. Если архитектура правильная, ну или назовите ее «удачная», то система поддается модификации и поддержке без больших потерь качества и производительности. А вот если архитектура плохая или я соглашусь на «неудачная», тогда имеем проблемы в очень многих ситуациях, практически неизлечимые без интервенции в Архитектуру решения. Слово «сложность» в данном случае это попытка оправдать неудачную архитектуру определенного продукта. Я уверен что Magento не проще а может и сложнее Bitrix, но судя по всему проблем значительно меньше. Так что дело не в псевдосложности Bitrix, а именно в его архитектуре. И я считаю что ООП не привносит особых изменений в производительность по определению, это всего лишь другой способ написания кода. Как его писать правильно — это отдельная история.
А может он просто не очень грамотно написан с точки зраения архитектуры? и подталкивает программистов к работе в режиме «костыль лучшее лекарство»? я не эксперт по битриксу, но из того что слышал это как бы не сборник «best practices», а скорее наоборот. Не хочу никого обидеть. :-) Кстати php ы этом смысле особенно до 7 не очень настаивает сам по себе на best practices. Считается практически одним из самых простых, порог входа в индустрию программирования со стороны php очень низкий. То есть доля недообразованных программистов в php значительно выше чем в других языках. Но зато нас намного больше! Берем количеством, а не качеством, так сказать :-(
Думаю, просто многие избегают даже произносить это слово :-)
Согласен. Вообще, мне кажется, это нормально когда следующая версия лучше предыдущей. Мне кажется это нормальное ожидаемое поведение. :-) Ненормально обратное поведение, когда следующая версия значительно хуже предыдущей.
Я может не совсем в теме. Но разве для HHVM не надо указать какой PHP она исполняет? У нее свой собственный PHP? не 5.6 и не 7.0 и не 7.2?

Информация

В рейтинге
Не участвует
Откуда
Montreal, Quebec, Канада
Дата рождения
Зарегистрирован
Активность