От статьи двоякое ощущение: с одной стороны, общая мысль правильная, изучайте то, что есть вокруг, не зацикливайтесь на одном инструменте.
С другой, примеры выбранные автором ниразу не мотивируют:
— Выбор РоР для проекта не обоснован и не раскрывает преимуществ РоР перед PHP.
— Пример кода сбивает с толку, т.к. совершенно нечитабельно то, что происходит (с точки зрения синтаксиса PHPшника). Возможность писать не так как обычно могла бы быть плюсом к ФП, но не здесь.
даже не зная как реализовать загрузку файлов в Ruby/Rails, я смог решить поставленную задачу
Радость от использования готовых гемов — аналогично когда человек вешает джумлу, у него получается сделать стандартные штуки типа регистрации или отправки сообщения и он со штанами полными радости кричит: «о дааа, теперь я знаю похапэ и могу о нем рассказывать неофитам»!
Лично я чувствую дискомфорт, когда я не понимаю как что-то работает. Потому что когда понадобится сделать что-то нестандартное, всё джедайство сразу сдуется.
Некоторое время назад решал похожую задачу получения видео с трех основных видеохостингов: RuTube, YouTube, Vimeo, получился такой класс. Йа ссылка
$v = new VideoThumb($link); //Процессим ссылку
$v->getVideo(); //Ссылка на видео
$v->getTitle(); //Название ролика
$v->fetchImage($to); //Скачать самое большое превью ролика в файл $to
Если водяной знак накладывать на лету, то да, достаточно будет одной версии.
Но моя идея в том, чтобы не хранить лишнее. Если я буду хранить оригиналы фотографий пользователя, то очень быстро уйду на энтерпрайз тариф. А если смогу пережимать их внутри хранилища до 1-2 мпикс, то мне хватит и начального тарифа :)
В статье не упомянуто текущее ограничение на размер обработки файлов на лету: 1024х634, а этого далеко не всегда достаточно даже для графики на сайте (retina наступает!)
Еще возникает вопрос как быть с таким сценарием: юзер заливает фото со своей зеркалки на 12-36 мпикс.
Я не хочу хранить эти дикие мегапикселы и хочу ужать картинку до размера 1280х1024, ну и показывать превью пережималкой на лету.
Из эффектов очень не хватает наложения водяного знака.
И кстати, тут возникает момент, что нужно хранить 2 версии большого изображения, одно с водяным знаком для показа в полный размер и одно для создания превью без водяного знака.
В Российских реалиях большой плюс схемы с тонкими клиентами и сервером, когда какие-нибудь нехорошие дяди конфискуют рабочие места по разным левым предлогам, можно восстановить работу офиса уже на следующий день и уберечь ценные данные от мародерства.
А вот внезапный переход с переднего на задний привод в процессе вождения на скорости — это из разряда к счастью не сбывшейся фантастики.
Zanuda mode on. Вообще нежданчики с изменяющимся поведением и приводом — это как раз особенности сбывшейся фантастики.
Начиная от автоматически подключаемого полного привода, заканчивая системами стабилизации, которые могут сильно менять поведение в сторону от ожидаемого именно на ходу без участия и доброй воли пользователя.
Каждому заметно, что пользователей мобильных устройств становится все больше и больше и их количество уже выше чем количество пользователей стационарных компьютеров. Это никого не может оставить равнодушным – большая аудитория это большие перспективы, большие деньги. И при таком положении дел политика Adobe выглядит очень верной – быть везде, работать быстрее, поддерживать все модное, чтобы никто больше не смог сказать, что Flash плох.
Все пользователи iOS негодуют. Правда отсутствие флеш на яблоках это политика яблок, но всё равно очень сильно отталкивает от флеша.
А если говорить про обычный web, то очень большую поддержку флеш оказали всякие Youtube`ы, если бы не они, флеш можно было бы вообще выключить, т.к. субъективно 80% того, что есть сейчас на флеше — это баннеры и реклама.
Если предыдущий монитор не был откалиброван, то причина может быть в цветопередаче.
Ну и ретина всё таки IPS, цветопередача лучше чем средний TN по больнице.
В данном случае, я уверен: то что можно автоматизировать — нужно автоматизировать.
Копипаста таит в себе незамеченные проблемы, а вдумчиво написать 100500 тестов на геттеры и сеттеры не получится, ибо скучно до зубовного скрипа. Средства малой механизации позволяют найти компромисс и не потерять в покрытии.
Ну и насчет понимания — этот тест не такой уж и сложный, код можно снабдить комментариями, а сообщения при ошибке точно дадут понять какой метод упал и почему. Дальше найти виновного уже дело техники.
Значит для каждого метода надо будет написать аннотацию с @ return, причем явно указать какой класс возвращается.
Соотв. автокомплит для унаследованных классов будет ущербный. Как по мне, лучше и понятнее написать return $this в теле метода, чем в аннотации, и не городить магию.
Инструмент кодогенерации не доктриновский, но аналогичный, да. Не очень понял зачем мне делать pull-request в ядро большого (?) фреймворка, если я работаю на уровне приложения и все геттеры\сеттеры относятся к реализации моей модели.
1. Вижу большое количество проблем при автокомплите в IDE. На данный момент PHPStorm не всегда корректно справляется с обычными методами, унаследованными от другого класса и возвращающими $this, а в такой обертке про автокомплит можно забыть.
А без автокомплита я слабо представляю себе продуктивную работу.
2. Проблема написания большого количества геттеров и сеттеров решается либо средствами IDE, либо с помощью кодогенерации.
К примеру, у меня есть схема БД, одной консольной командой по ней генерируется базовый класс со всеми геттерами и сеттерами. Потом он наследуется «основным» и в нем уже вся реализация логики приложения.
При изменении схемы базовый класс автоматически перегенерируется, не затрагивая логику.
С другой, примеры выбранные автором ниразу не мотивируют:
— Выбор РоР для проекта не обоснован и не раскрывает преимуществ РоР перед PHP.
— Пример кода сбивает с толку, т.к. совершенно нечитабельно то, что происходит (с точки зрения синтаксиса PHPшника). Возможность писать не так как обычно могла бы быть плюсом к ФП, но не здесь.
Радость от использования готовых гемов — аналогично когда человек вешает джумлу, у него получается сделать стандартные штуки типа регистрации или отправки сообщения и он со штанами полными радости кричит: «о дааа, теперь я знаю похапэ и могу о нем рассказывать неофитам»!
Лично я чувствую дискомфорт, когда я не понимаю как что-то работает. Потому что когда понадобится сделать что-то нестандартное, всё джедайство сразу сдуется.
Очень странная фраза, ведь эксель тоже стоит денег. Дедушка поставил сборку все-в-одном с торрента?
Некоторое время назад решал похожую задачу получения видео с трех основных видеохостингов: RuTube, YouTube, Vimeo, получился такой класс. Йа ссылка
Не очень понятно, а что должно происходить при клике на электропочту?
Но моя идея в том, чтобы не хранить лишнее. Если я буду хранить оригиналы фотографий пользователя, то очень быстро уйду на энтерпрайз тариф. А если смогу пережимать их внутри хранилища до 1-2 мпикс, то мне хватит и начального тарифа :)
Еще возникает вопрос как быть с таким сценарием: юзер заливает фото со своей зеркалки на 12-36 мпикс.
Я не хочу хранить эти дикие мегапикселы и хочу ужать картинку до размера 1280х1024, ну и показывать превью пережималкой на лету.
Из эффектов очень не хватает наложения водяного знака.
И кстати, тут возникает момент, что нужно хранить 2 версии большого изображения, одно с водяным знаком для показа в полный размер и одно для создания превью без водяного знака.
Zanuda mode on. Вообще нежданчики с изменяющимся поведением и приводом — это как раз особенности сбывшейся фантастики.
Начиная от автоматически подключаемого полного привода, заканчивая системами стабилизации, которые могут сильно менять поведение в сторону от ожидаемого именно на ходу без участия и доброй воли пользователя.
Все пользователи iOS негодуют. Правда отсутствие флеш на яблоках это политика яблок, но всё равно очень сильно отталкивает от флеша.
А если говорить про обычный web, то очень большую поддержку флеш оказали всякие Youtube`ы, если бы не они, флеш можно было бы вообще выключить, т.к. субъективно 80% того, что есть сейчас на флеше — это баннеры и реклама.
Ну и ретина всё таки IPS, цветопередача лучше чем средний TN по больнице.
Копипаста таит в себе незамеченные проблемы, а вдумчиво написать 100500 тестов на геттеры и сеттеры не получится, ибо скучно до зубовного скрипа. Средства малой механизации позволяют найти компромисс и не потерять в покрытии.
Ну и насчет понимания — этот тест не такой уж и сложный, код можно снабдить комментариями, а сообщения при ошибке точно дадут понять какой метод упал и почему. Дальше найти виновного уже дело техники.
В этом нашем похапэ можно сделать что-то такое например:
Добавить одну строчку для новой пары сеттер-геттер не такая уж страшная работа.
Соотв. автокомплит для унаследованных классов будет ущербный. Как по мне, лучше и понятнее написать return $this в теле метода, чем в аннотации, и не городить магию.
Инструмент кодогенерации не доктриновский, но аналогичный, да. Не очень понял зачем мне делать pull-request в ядро большого (?) фреймворка, если я работаю на уровне приложения и все геттеры\сеттеры относятся к реализации моей модели.
А без автокомплита я слабо представляю себе продуктивную работу.
2. Проблема написания большого количества геттеров и сеттеров решается либо средствами IDE, либо с помощью кодогенерации.
К примеру, у меня есть схема БД, одной консольной командой по ней генерируется базовый класс со всеми геттерами и сеттерами. Потом он наследуется «основным» и в нем уже вся реализация логики приложения.
При изменении схемы базовый класс автоматически перегенерируется, не затрагивая логику.