Даже, если будет по вашему, но оно будет работать не медленнее, чем сейчас, я не против. Я против вариантов с приведением типов (даже автоматическим), или варианта, когда вся память будет засрана строками-объектами.
Не вижу особого смысла. Почему не к виду \String\length()?
Потому что это по прежнему процедурный стиль. Например, можно засунуть свою функцию в \String. Я против этого, будет тоже самое, что с глобальными массивами. С другой стороны можно сделать ProjectString extends String, чтобы расширить функционал, но сохранить целостность. Для нэймспейсов так не сделаешь.
Согласен, но с небольшой оговоркой. Вот как раз про strlen. Я, лично, не сторонник перевода базовых типов в объекты. Т.е. я не хочу, чтобы все строки внезапно стали объектами. И тем более не хочу раздвоения, когда есть и string, и String. Это никому не нужно. Но все методы для работы со строками привести к виду String::length() — вот это то, чего я хочу. Более того, это даже сделать можно относительно не сложно. Надо только научиться писать расширения, потому что такие обертки на PHP будут тормозить приложение.
1. Мое нежелание тут не причем. Подход должен быть единым, а не половина ошибок через исключения, вторая — через фаталы. Ничего нормального в этом нет при любом раскладе вне зависимости от моего и вашего понимания этого вопроса. Подчеркиваю — в этом нет даже нормальности, не говоря о том, что это может быть хорошо. Такой подход был актуален до появления исключений.
2. Я не против сочетания ООП-подхода и процедурного, если для ООП все написано как положено, в объектном стиле. Т.е. полное дублирование (естественно через обертки) всего коробочного функционала — для работы в процедурном стиле, и ООП. А то, что сейчас все перемешано — это одна из серьезнейших проблем языка.
То, что дело дошло до перевода фаталов в исключения — это очень хорошо. Если это примут, писать и обслуживать приложения станет проще и удобнее. Жалко, что до этого добрались так поздно.
Вообще, в PHP есть только несколько серьезных концептуальных проблем. Вот фаталы — одна из них. Может их по-тихоньку выпилят и язык обретет новую жизнь. По сути главное, что надо еще сделать, — это полностью переписать все стандартные функции, классы и все, что с ними идет, но объектный и единый стиль, избавиться от хаоса именований и подходов. Т.е. привести всю внутрянку в нормальный вид.
Это что касается самого языка. А что касается среды исполнения, то тут надежды на HHVM. Если Facebook не забъет на этот проект и сообщество его подхватит, это станет новая дефолтовая среда для исполнения PHP, на порядок лучше старой интерпретации.
Если каким-то чудом срастется это все, то у PHP однозначно начнется новая жизнь.
Мне тоже кажется, что такой многословный код со стороны пользователя библиотеки не нужен. Если подумать, все действия можно было описать в декларативном стиле с параметрами. При необходимости некоторой кастомизации передавать в параметрах колбеки.
Вот мне, например, требуется такой алгоритм (пока не понял, возможен ли он с вашей либой):
1) 2 кнопки: выбрать файл | сделать фото;
2) если делаем фото, открывается снималка;
3) если выбираем файл или после сделанного фото, открывается кропалка;
4) файл заливается на сервер.
Не понял пока, можно ли совместить камеру и кроп. Хотя даже если нельзя, это не жизненно критично.
Так вот как бы я хотел это описать на JS:
var a = FileApi({
url: 'url.php',
max_...: ...,
...
});
$('#select-photo').on('click', a.delegate(['select', 'crop', 'upload']);
$('#cam').on('click', a.delegate(['cam', 'crop', 'upload']);
Я понимаю всю наивность такого подхода, но считаю, что если все круто продумать, то новых проблем это не создаст. Вот вы пользуетесь МакОсью. Наверное, знаете про ее 100500 ограничений в стиле Эппл решил что для вас лучше так, и вариантов больше нет. Но все равно все довольны (кроме мня). Так же и тут. Некоторые возможности можно закрыть, но вместо это дать на порядок более простой API, который устроит 98 % пользователей.
Конечно, в моем примере можно было вместо строк в массиве порядка действий дать хэши с параметрами (если нужно), с колбеками, которые будут делать кастомизацию. Т.е. тот АПИ, что есть сейчас, он никуда не денется, просто над ним будет офигенная обертка. Именно об этом и пишут люди в комментах. В этой ветке, и веткой выше.
Ок, спасибо. Значит все же «написать программу» недостаточно, и вы это подтверждаете. Более того, это даже не первый барьер на собеседовании, т.е. вы предлагаете поработать с кодом не сразу и не всех. Вот тут очень интересно, как вы заканчиваете собеседование после первого этапа, если он провален? Вы сообщаете кандидату сразу, что он не подходит? Или отпускаете его с мнением, что собеседование у вас в компании — это несколько простых вопросов за 20 минут?
Вы рассказываете о свеой компании до начала разговора? Этот вопрос для меня особо актуален. Рассказывать о себе в начале как-то не могу воспринимать. А отвечать на вопросы о себе в конце, когда понятно, что эту человеку будет дан отказ (иногда решение принято уже во время собеседования) — это неприятно и чувствуешь себя лжецом.
Вопрос же не в том, что надо переделать. А в том, какие тут ошибки. И смысл в том, чтобы оценить то подмножество ошибок, которые заметит кандидат, и то, как он их объяснит. Хотя можно дать и меньший по размеру код с меньшим числом ошибок, или несколько вариантов разного кода с разными ошибками, но в меньшей концентрации. Короче, суть в подходе, а не в реализации.
Людей я за свои 19 лет профессиональной деятельности набирал неоднократно (мягко говоря), кандидатов через меня, наверное, сотни три прошло в общей сложности. Свой подход к решению этой проблемы выработал уже давно. На мой взгляд — работает он хорошо.
Значит, действительно я не понимаю вас. И мне кажется, что вина в том не моя. По сути вы не раскрыли ничего, кроме фразы «Именно, попросить написать программу». Если не лень, напишите об этом подробнее, пожалуйста, как минимум мне это весьма интересно. Если лень, тогда действительно вопрос надо закрывать, потому что в общем случае подход «попросить его написать программу» не работает. ТЗ сейчас практикуется только в качестве дополнения, но никак не основы.
Если вы берете на работу программиста, чтобы он программировал, то надо бы проверить, насколько хорошо он программирует.
Можно узнать, как? Попросить его написать программу, что ли?
Либо я действительно не понимаю вашу мысль, либо вы никогда не отбирали людей и не понимаете, что это такое. Дело в том, что выше описан один из способов «проверить, насколько хорошо он программирует». Это моя мысль, и я бы хотел донести ее до вас.
Нет, мне кажется ваша аналогия вобще не в тему. Любой врач должен владеть очень широким общим набором знаний из медицины. И хирург, и лор. У программистов тоже самое — есть вещи, которые должны знать все, вне зависимости от того, что именно человек будет делать на своей позиции. Это уже сто-пиццот раз обсуждалось, и объяснять это смысла наверное нет. Так вот, здесь проверяется не способность анализировать код (это к вашей аналогии), а именно знания и опыт в предметной области. Увидьте разницу: не проверить, как он может проводить код-ревью, а через код-ревью попытаться оценить его уровень. Совершенно разные вещи.
Я тоже прихожу к чему-то подобному. Постоянно провожу собеседования, постоянно пробую что-то новое. В итоге понмаю, что вытянуть информацию из человека вопросами зачастую непросто. Так что пусть сам все выдаст.
Вообще, такая практика не нова. Уже были предложение на собеседовании меняться ролями. Мол, я хорошо оценю кандидата по его вопросам. Понятно, что на практике это чаще не работает, потому что собеседовать могут далеко не все специалисты, особенно без подготовки.
На последнем собеседовании я попробовал нечто похожее. Только я не код дал, а схему классической архитектуры среды, в которой работает веб-приложение. Я хотел понять, что человек знает о той среде, в которой работает его код. Честно говоря, с результат мне не очень понравился — по ответу я не смог сделать однозначный вывод.
Судя по всему, попробую ваш вариант с анализом кода.
Такие статьи обычно пишут люди экспертного уровня, которые отлично разбираются в архитектурах и паттернах. Да, такие люди умеют делать те самые патчи правильно. И они умеют из этих патчей сложить качественный (т.е. не глючный, что весьма не тривиально на самом деле), сложный (в плане комплексный) и нужный продукт. Они пользуются знаниями, не замечая того. Они делают все просто, потому что умеют делать это просто! Да, это KISS. И да, этому надо учиться.
А теперь вопрос: как этому учиться? Как отличить простое от сложного, если не знаешь, что такое сложное?
Чтобы достичь этого уровня как раз и надо упорно изучать архитектуру, паттерны, алгоритмы. И нужно владеть базовыми, фундаментальными знаниями.
А кричать в рупор «забейте на все и делайте простые пачти» — создание дополнительных барьеров для новичков, которые будут смотреть не в том направлении и писать глупости в комментах на Хабре.
А будет ли кнопка «Сохранить в Яндекс.Диск» по URL без предварительной загрузки файла (как в виджете)? Например, у Dropbox такая кнопка есть. Конечно, можно реализовать «это» и своими силами, используя API, но это на порядок (а то и 2 сложнее). Просто передавать URL, который надо сохранить, намного проще, а следовательно и пользовалось бы большей популярностью.
Самый простой пример — сайт по поиску персонала. HR мог бы сохранять на Диск резюме соискателей в PDF.
Только отмечу, что в мои обязанности входит не только разработка (по большей части руководство и архитектура), но и построение инфраструктуры и обслуживание работающих проектов (опять же на уровне архитектуры и руководства). Может быть по-этому я особенно ценю свои знания в сетях.
Вообще, как писали выше, чтобы получить фундаментальные знания по базовым дисциплинам достаточно действительно прочитать подряка 5 книг. Причем, сети полностью и операционные системы (межпроцессное взаимодействие в частности) полностью покроют 2 книги Танненбаума, написание нормального кода — Боб Мартин, паттерны — тут уже по вкусу из нескольких вариантов. Т.е. все не так сложно, но очень полезно.
И да, так как знания удаляются, предлагаю не изучать математику после 5 класса, т.к. в жизни ей почти никто не пользуется. Извечный вопрос — учить или не учить. И ответ по-моему очевиден.
Я понимаю то, что сам использую эти знания постоянно. telnet-ом слал POST-ы ровно вчера, tcpdump-ом смотрел трафик месяц назад. При проектировании все это нужно, все это используется. И спорить, извините, не буду. Свою позицию я озвучил и обосновал.
На столько, на сколько и другие программисты, которые разрабатывают клиент-сервер. Эти знания нужны, чтобы делать осознанный выбор технологий, находить трудноуловимые ошибки взаимодействия, в том числе на продакшане, разрабатывать защищенные системы.
С вами мне уже все ясно. Ваше отношение к интервьюеру и манеры общения отодвигают все остальное на второй план. Неуважение хорошо читается в процессе разговора с умными и уверенными в себе людьми. Возможно есть и другие моменты (типа больших теоретических пробелов), но это уже не более чем догадки. И цель написания этой статьи для меня тоже очевидна — потешить самолюбие. Это мое личное мнение, которые сформировано вашим текстом статьи и ответами в комментах. С таким подходом вам действительно будет сложно пройти 90 % самых адекватных собеседований.
Даже, если будет по вашему, но оно будет работать не медленнее, чем сейчас, я не против. Я против вариантов с приведением типов (даже автоматическим), или варианта, когда вся память будет засрана строками-объектами.
Потому что это по прежнему процедурный стиль. Например, можно засунуть свою функцию в \String. Я против этого, будет тоже самое, что с глобальными массивами. С другой стороны можно сделать ProjectString extends String, чтобы расширить функционал, но сохранить целостность. Для нэймспейсов так не сделаешь.
2. Я не против сочетания ООП-подхода и процедурного, если для ООП все написано как положено, в объектном стиле. Т.е. полное дублирование (естественно через обертки) всего коробочного функционала — для работы в процедурном стиле, и ООП. А то, что сейчас все перемешано — это одна из серьезнейших проблем языка.
Вообще, в PHP есть только несколько серьезных концептуальных проблем. Вот фаталы — одна из них. Может их по-тихоньку выпилят и язык обретет новую жизнь. По сути главное, что надо еще сделать, — это полностью переписать все стандартные функции, классы и все, что с ними идет, но объектный и единый стиль, избавиться от хаоса именований и подходов. Т.е. привести всю внутрянку в нормальный вид.
Это что касается самого языка. А что касается среды исполнения, то тут надежды на HHVM. Если Facebook не забъет на этот проект и сообщество его подхватит, это станет новая дефолтовая среда для исполнения PHP, на порядок лучше старой интерпретации.
Если каким-то чудом срастется это все, то у PHP однозначно начнется новая жизнь.
Вот мне, например, требуется такой алгоритм (пока не понял, возможен ли он с вашей либой):
1) 2 кнопки: выбрать файл | сделать фото;
2) если делаем фото, открывается снималка;
3) если выбираем файл или после сделанного фото, открывается кропалка;
4) файл заливается на сервер.
Не понял пока, можно ли совместить камеру и кроп. Хотя даже если нельзя, это не жизненно критично.
Так вот как бы я хотел это описать на JS:
Я понимаю всю наивность такого подхода, но считаю, что если все круто продумать, то новых проблем это не создаст. Вот вы пользуетесь МакОсью. Наверное, знаете про ее 100500 ограничений в стиле Эппл решил что для вас лучше так, и вариантов больше нет. Но все равно все довольны (кроме мня). Так же и тут. Некоторые возможности можно закрыть, но вместо это дать на порядок более простой API, который устроит 98 % пользователей.
Конечно, в моем примере можно было вместо строк в массиве порядка действий дать хэши с параметрами (если нужно), с колбеками, которые будут делать кастомизацию. Т.е. тот АПИ, что есть сейчас, он никуда не денется, просто над ним будет офигенная обертка. Именно об этом и пишут люди в комментах. В этой ветке, и веткой выше.
Вы рассказываете о свеой компании до начала разговора? Этот вопрос для меня особо актуален. Рассказывать о себе в начале как-то не могу воспринимать. А отвечать на вопросы о себе в конце, когда понятно, что эту человеку будет дан отказ (иногда решение принято уже во время собеседования) — это неприятно и чувствуешь себя лжецом.
Значит, действительно я не понимаю вас. И мне кажется, что вина в том не моя. По сути вы не раскрыли ничего, кроме фразы «Именно, попросить написать программу». Если не лень, напишите об этом подробнее, пожалуйста, как минимум мне это весьма интересно. Если лень, тогда действительно вопрос надо закрывать, потому что в общем случае подход «попросить его написать программу» не работает. ТЗ сейчас практикуется только в качестве дополнения, но никак не основы.
Можно узнать, как? Попросить его написать программу, что ли?
Либо я действительно не понимаю вашу мысль, либо вы никогда не отбирали людей и не понимаете, что это такое. Дело в том, что выше описан один из способов «проверить, насколько хорошо он программирует». Это моя мысль, и я бы хотел донести ее до вас.
Вообще, такая практика не нова. Уже были предложение на собеседовании меняться ролями. Мол, я хорошо оценю кандидата по его вопросам. Понятно, что на практике это чаще не работает, потому что собеседовать могут далеко не все специалисты, особенно без подготовки.
На последнем собеседовании я попробовал нечто похожее. Только я не код дал, а схему классической архитектуры среды, в которой работает веб-приложение. Я хотел понять, что человек знает о той среде, в которой работает его код. Честно говоря, с результат мне не очень понравился — по ответу я не смог сделать однозначный вывод.
Судя по всему, попробую ваш вариант с анализом кода.
А теперь вопрос: как этому учиться? Как отличить простое от сложного, если не знаешь, что такое сложное?
Чтобы достичь этого уровня как раз и надо упорно изучать архитектуру, паттерны, алгоритмы. И нужно владеть базовыми, фундаментальными знаниями.
А кричать в рупор «забейте на все и делайте простые пачти» — создание дополнительных барьеров для новичков, которые будут смотреть не в том направлении и писать глупости в комментах на Хабре.
Самый простой пример — сайт по поиску персонала. HR мог бы сохранять на Диск резюме соискателей в PDF.
Можно ли рассчитывать на появление такой кнопки?
Вообще, как писали выше, чтобы получить фундаментальные знания по базовым дисциплинам достаточно действительно прочитать подряка 5 книг. Причем, сети полностью и операционные системы (межпроцессное взаимодействие в частности) полностью покроют 2 книги Танненбаума, написание нормального кода — Боб Мартин, паттерны — тут уже по вкусу из нескольких вариантов. Т.е. все не так сложно, но очень полезно.
И да, так как знания удаляются, предлагаю не изучать математику после 5 класса, т.к. в жизни ей почти никто не пользуется. Извечный вопрос — учить или не учить. И ответ по-моему очевиден.