Запомните 2 аксиомы:
1. "Плохие программисты думают о коде, хорошие о архитектуре".
2. "Любой дурак сможет написать код, который поймет машина. Хорошие программисты пишут код, который сможет понять человек."
- Абстрагируйтесь от инструментов и научитесь видеть проблему - отлично помогает в этом написание кода на бумаге, только не слепые попытки вспомнить синтаксис пхп, а решение реальной задачи. Ошибки будут и они не имеют значения, их исправит ваша "среда разработки", но вы привыкните к планированию.
- Возьмите последнюю задачу, которую решали и реализуйте как минимум 10 способов ее решения. Опишите на листке бумаги + / - каждого. Не забывайте о том, что легкость понимания кода в сотни раз важнее производительности (бывают исключения, но когда вы с ними столкнетесь подобных вопросов задавать не будете и ответ будете знать лучше меня.) Найдите оптимальное решение и используйте рефакторинг для того, чтобы внедрить "лучшие" части других решений. Напишите тесты. Делайте рефакторинг и тестируйте регулярно. Начните применять TDD.
p.s. меньше читайте. Разберитесь с тем, что такое "ошибка выжившего" и постарайтесь понять, что пути становления описанные сотни раз на примерах -это не всегда то, что вам нужно. Вы особенный, как и любой человек и вам нужен свой подход. То, что пишут в книгах и статьях "успешные" программисты, это всего лишь часть шагов, многе из которых не являются необходимостью и тем более достаточной, те же шаги, которые описанны выше -необходимость которой будет достаточно для того, чтобы стать "хорошим программистом".
nevro: ну если прям фото, то нужно преобразовывать в разные разрешения \ размеры и буквально отдавать разные изображения, другого эффективного пути с контролируемым качеством и без сложных вычислений я не вижу. Но опять же, это веб и тут не нужна печатная четкость, потому можно попробовать разные способы конвертации и даже jpeg \ png преобразовать в svg вполне реально, вопрос в стоимости и тут нужно испытывать в своих условиях доступные по стоимости и возможности реализации средства.
Сергей Протько: Мертв.. ну и что? он отлично решал и решает свою задачу, задача не изменилась, расширять ее у меня нет необходимости -он работает. Да и я могу использовать тот же gulp, это не проблема, я просто не фанат всех этих тулзов и если уж использую -то довольно ограниченно для минимума задач, опять же не привязанны к отдельному препроцессору для меня спорный аргумент, я уже пояснял почему предпочитаю sass и главное то, что я считаю, что scss -это будущий стандарт css. Я буквально считаю остальное спамом. Хотя и не говорю, что в случае необходимости не готов использовать тот же less. Compass -это вообще просто инструмент который использую просто по привычке и довольно примитивно, миксины я их не использовал очень давно. И я не вижу повода для его смерти -он поддерживается и используется, не развивается для ширкой публики -не страшно, я и не гонюсь за медийностью и попсовостью технологий. Вон bootstrap 4 уже будет работать с sass и даже не смотря на то, что у них явно были причины довольно масштабного изменения я сильно сомневаюсь, что less умрет. Все подобные технологии выростают из команд, которые разрабатывали их под свои задачи, выстрелило -ок, есть желание развивать и поддерживать сообщество -ок, нет -ок, задачи сообщества широкие, но это не значит что игнорируя их он не решает своей задачи.
Сергей Протько: к слову по поводу compass, я конечно не сомневаюсь, что уже есть достаточно альтернатив, но зачем их искать, когда он работает. К примеру возможность сжатия кода или этого самого сжатия отмены, с целью отладки -удобная штука.
К тому же там есть полезные команды к которым просто привыкаешь, даже просто создавая проект compass create, помогает лентяям вроде меня. Плюс вполне удобно использовать вместе с тем же grunt. Ну а если к нему привыкаешь без отвращения, значит хороший инструмент.
Мне кажется время его жизни на сегодняшний день и все еще актуальность, всеже говорит о надежности и это скорее плюс.
Сергей Протько: дело в том, что я отвеал на конкретный вопрос по поводу sass, и лично я вообще не разделяю его с less, поскольку считаю, что изучив одно, проблем со вторым не будет. Разница примитивна и не существенна... более того я склоняюсь к мнению о том, что на первом месте стоит задача, а не технология. И именно благодаря тому, что они так взаимозаменяемы (по крайней мере в моей голове) я не вижу смысла в stylus. Все же я подразумевал в контексте нового пользователя, для которого scss будет более чем достаточно. Если стандарты разойдутся или если будет возможность исключить less из головы, я уверен, что с успехом буду работать с новыми стандартами pure css, понимая scss, но оставаться исключительно с less -не вижу возможным. Т.е. вывод для меня прост, да сегодня less и sass -взаимозаменямы, но глядя в будущее, я могу взять того, кто категорически на сторое sass на работу, но не того, кто есть адепт исключительно less. Stylus я вообще не видел очень давно и рассматриваю подобное как спам для своего мозга, в котором не так много свободного места...
Yanula: Только тематические группы, тот же reddit, g+, twitter, facebook. Вам нужно получить подписчиков либо купить, либо влиться в существующее тематическое сообщество.
Александр: значит вам не много упростили задачу, просто привяжите к каждому продукту колличество каллорий, когда результат не удовлетворителен согласно программе уменьшите каллории, просто просчитав рацион и исключив колличество, к примеру убрав хлеб или разрезав яблоко. Т.е. просто Продукт как класс, но вычисления выполняются по его свойствам.
Тут суть очень простая, вам нужно просто изучить предмет. К примеру есть различные методики похожения, к примеру без углеводная диета или другие (я не особо в деталях разбираюсь), эти программы предлагают свое колличество калорий из ряда продуктов, вам нужно иметь желаемый результат и сравнивать результат пользователя, если пользователь отстает, с учетом его программы (типа диеты) вы должны брать список продуктов, разбирать из по составу и формировать оптимальный.
Я бы сделал для начала трекер, которой позволит следить за пользователем, взять его вес и в течении месяца отслеживать питание и изменения. Каждый продукт разкладываете на состав и составляете статистику по углеводам \ белкам и т.д. В дальнейшем анализируете best practice и делаете предложения. Ну а если результат не удовлетворительный, то к примеру вы всегда можете определить продукт с наиболее большим содержанием к примеру быстрых углеводов и исключить его.
Никакого api или открытого кода вам не дадут, обычно методики авторские и приносят деньги, но вы вполне можете разложить продукт по составу, а каждому элементу выставить приоритет (что больше, а что меньше влияет), но вообще это может быть довольно сложная задача.
Suntechnic: Варриант увеличить колличество серверов никто не отменял, а на сколько я помню заявляли как то они, что используют более 10 000 совсем не слабых машин из которых фронтендом занимаются штук 30, я бы не сказал, что такие цифры - это плюсы для php как серверной технологии. Да и костылей там много, уверенн.
Suntechnic: в том то и дело, что фреймворк подразумевает кучу в большинстве случаев не нужных и далеко не оптимальных зависимостей и как раз в laravel эту архитектуру придется "наследовать" иначе получится такая каша, что легче действительно на велосипед сесть... Все его IoC \ Di успешно применяются и без кучи зависимостей, удаление которых сводит весь фреймворк к банальной файловой структуре. Слишком уж тяжеловесен laravel и подобное, его мир - это CMS -ки и всякие там прототипы расчитанные на переписать в будущем, как деньги пойдут... Даже зенд тут лучше с его модульностью. Все, что в highload нужно на этом уровне - быстрая обработка \ формирование запросов к бд и потому лично я бы из скриптов выбрал perl, хотя опять java куда очевидней в качестве решения.
я подозреваю, что в ubuntu, apt-cache search cinnamon - решит проблему. Unity или gnome - какая разница? Первое, что нужно сделать новичку - работать в терминале и первое время вообще про gui забыть. Это linux и выбирать дистрибутив по оболочке - идиотизм.
Если честно меня пугает человек советующий новичку CentOS, я так и Gentoo предложить могу... Особенно с учетом того, что личный ПК -это не только LAMP. Все ответы тут: fedoraproject.org/ru
Да думаю с циклом варриант пройдет, врятли придется слишком много букв перебирать. Ну а с путем сохранения попробую объяснить заказчику, какой это геморой и предложить просто вводить путь руками/копировать вместо browse. :)
1. "Плохие программисты думают о коде, хорошие о архитектуре".
2. "Любой дурак сможет написать код, который поймет машина. Хорошие программисты пишут код, который сможет понять человек."
- Абстрагируйтесь от инструментов и научитесь видеть проблему - отлично помогает в этом написание кода на бумаге, только не слепые попытки вспомнить синтаксис пхп, а решение реальной задачи. Ошибки будут и они не имеют значения, их исправит ваша "среда разработки", но вы привыкните к планированию.
- Возьмите последнюю задачу, которую решали и реализуйте как минимум 10 способов ее решения. Опишите на листке бумаги + / - каждого. Не забывайте о том, что легкость понимания кода в сотни раз важнее производительности (бывают исключения, но когда вы с ними столкнетесь подобных вопросов задавать не будете и ответ будете знать лучше меня.) Найдите оптимальное решение и используйте рефакторинг для того, чтобы внедрить "лучшие" части других решений. Напишите тесты. Делайте рефакторинг и тестируйте регулярно. Начните применять TDD.
p.s. меньше читайте. Разберитесь с тем, что такое "ошибка выжившего" и постарайтесь понять, что пути становления описанные сотни раз на примерах -это не всегда то, что вам нужно. Вы особенный, как и любой человек и вам нужен свой подход. То, что пишут в книгах и статьях "успешные" программисты, это всего лишь часть шагов, многе из которых не являются необходимостью и тем более достаточной, те же шаги, которые описанны выше -необходимость которой будет достаточно для того, чтобы стать "хорошим программистом".