)))) Очень любил первый ZF (второй конечно, разочаровал), но да, лэйауты, хелперы, экшены, роуты ) и полное отсутствие модели и какого-бы то ни было best practice.
Спасибо.
Сама статья довольно поверхностная, но такой общий взгляд тоже важен — для понимания в целом.
За комментарии отдельное спасибо — много ценного почерпнул.
Ограничиваться только Канбаном в управлении командой веб-разработчиков, довольно сложно, и даже рисковано. Хотя, конечно, все зависит от команды.
На мой взгляд он всего лишь один из инструментов, довольно высокоуровневый, предназначенный, в первую очередь, для управления самим процессом «производства» и хорошо подходит для команд, построивших конвеер разработки (например, разработка сайтов на потоке).
Я совсем не против выхода за рамки, но тогда уж будьте последовательны и представьте работающее решение.
Измерить высоту здания кидая с него барометр и замеряя время падения — работает. А жить в одной стене — нет )
> Фигассе не привёл. Тибетский домик в горах — неправильно? Весы с кукушкой — неправильно?
Конечно нет. Во первых, это не решение (расщелина не настолько узка, что обе стены были параллельны и не имели перпендикулярной стены, не говоря уже про то, что домик построен; часы всего лишь перекосятся, фальшивая монета может быть и в самой нижней точке и в самой верхней — фейл,...), это всего лишь отмазки из разряда «любым способом» — не попытка решить задачу, а всего лишь попытка использовать неточность постановки задачи, чтобы решить ее неправильно. Я знаю таких разработчиков — если дать им возможность реализовать задачу неверно, они обязательно так и сделают — в силу своей природной лени, видимо )
Решения могут выходить из плоскости задачи и тогда это действительно гениальные решения (как автомат Калашникова — все пытались сделать зазоры меньше, чтобы препятствовать попаданию внутрь всякой шняги типа песка и воды, а чел сделал наоборот — чтобы песок и вода спокойно вываливались наружу и ничему не вредили), но тут явно не этот случай. Хотя вариант с часами — хорошая попытка, но все-таки нет, а значит фэйл — в очередной раз по вине программиста спутник упал, поезда столкнулись )
Задачи интересные и довольно известные, но если бы я отбирал сотрудников такими задачами, уверен, лишился бы самых лучших из них )
Такие задачи иногда подбрасываю разработчикам для расширения сознания с тегом «а слабо не гугля»?
Честно говоря, не нравятся обе ваши картинки. На мой взгляд, такого допускать не стоит ни в какой системе.
И то, в какой ветке было сделано какое-то изменение не имеет смысла. Имеет смысл то, в какой ветке есть это изменение, а в каких — нет.
Есть ощущение, что Mercurial круче и гибче, но из поста так и не смог вкурить чем же именно.
Как это часто бывает, пересев с Svn на Git испытал чувство экстаза. Все, что работало плохо и часто ломалось в Svn в Git просто великолепно реализовано. И сам процесс разработки с переездом на Git сразу сдвинулся с места. Конечно, ограничения ощущаешь лишь со временем, но до сих пор Git позволяет мне вести процесс разработки так, как мне нужно и удобно.
Возможно так и надо подходить к вопросу — если встают непреодолимые препятствия или существенные ограничения, то да, пора «менять кобылу». Но пока она везет и достаточно резво, какой резон пересаживаться на другую? Мне кажется в этом основная причина того, что Git — мэйнстрим. Он достаточно хорош, чтобы его использовать, а его ограничения не настолько критичны, чтобы переводить с него процесс на mercurial, в котором, кончено же, со временем тоже почувствуются свои ограничения.
Git очень гибок и в этом его минус, если не умеешь им пользоваться. Он дает огромное количество инструментов и надо их изучать.
Сейчас наш workflow построен так, что я точно знаю, где и когда было сделано то или иное изменение и когда оно выйдет в свет.
История проста и понятна и по ней я могу точно сказать, где именно был сделан тот или иной коммит и когда он попал в ту или иную ветку. Это видно по истории. Это в git решается не на уровне самой системы, а на уровне организации процесса. По крайней мере, у меня так.
Даже не просветленному понятно, что нормальный вариант не две кнопки, а одна — плэй/пауза — в зависимости от текущего состояния.
А у вас как-то совсем далеко от идеала.
Самизнаетекто конечно сделал, конечно, шикарный подарок. Не ожидал, что сам отдаст рынок на растерзание.
Фрилансим понравился. Очень простой и достаточно удобный. Вы молодцы, другого и не ожидал, если честно.
Сырости не заметил. Если это бета, то просто супер.
Из замечаний — если при редактировании профиля ввести ссылку на сайт и не заполнить несколько полей, то при вводе значений из сайта вырезается http:// и при повторном сохранении выдает ошибку про некорректно заполенное поле.
Немного пугает, потому, что адрес написан нормально, а выдает ошибку.
Если туда снова дописать http://, то уже сохраняется без ошибки.
И лучше сделать совсем без http:// а при сохранении уже разбирать — пришло оно или нет.
Черт,… как же все предсказуемо.
Многое пересекается. Даже «инициалы», в свое время )
Лес абстракций или голый код — зависит от задачи. Иногда нужно быстро и на раз — сделал/сдал, а иногда поднять большую систему, зная, что тебе же её придется, поддерживать и развивать. Тогда и паккаджи/абстракции/прототипы/конфиги/тесты/ и куча еще всего скучного.
Сони со своим планированием профукала айпод + айтюнс и это при том, что они придумали саму концепцию «музыки в кармане».
Так же, как и Майкрософт — айпад, у них он был, если не ошибаюсь, за 4 года до эппловского, но, конечно, совершенно без понимания для чего он нужен и как он должен работать. Как впрочем и много еще чего :)
Иногда складывается ощущение, что пока крупные игроки планируют молодые хватаются за идею и делают её.
Ну вот дефолтный и надо поменять. Рамблеру.
Направление хорошее, по дизайну немного не дотянули, имхо.
Плюс сейчас надо активно пробиваться — расталкивать конкурентов — этого у рамблера не видно. А так далеко не уедешь.
По сути топика — весь вопрос в том, кто может «жать на кнопку».
Нового немного, но такая выжимка позволяет посмотреть на вопрос комплексно и задуматься.
Сама статья довольно поверхностная, но такой общий взгляд тоже важен — для понимания в целом.
За комментарии отдельное спасибо — много ценного почерпнул.
Поставим, посмотрим.
На мой взгляд он всего лишь один из инструментов, довольно высокоуровневый, предназначенный, в первую очередь, для управления самим процессом «производства» и хорошо подходит для команд, построивших конвеер разработки (например, разработка сайтов на потоке).
Я совсем не против выхода за рамки, но тогда уж будьте последовательны и представьте работающее решение.
Измерить высоту здания кидая с него барометр и замеряя время падения — работает. А жить в одной стене — нет )
Конечно нет. Во первых, это не решение (расщелина не настолько узка, что обе стены были параллельны и не имели перпендикулярной стены, не говоря уже про то, что домик построен; часы всего лишь перекосятся, фальшивая монета может быть и в самой нижней точке и в самой верхней — фейл,...), это всего лишь отмазки из разряда «любым способом» — не попытка решить задачу, а всего лишь попытка использовать неточность постановки задачи, чтобы решить ее неправильно. Я знаю таких разработчиков — если дать им возможность реализовать задачу неверно, они обязательно так и сделают — в силу своей природной лени, видимо )
Решения могут выходить из плоскости задачи и тогда это действительно гениальные решения (как автомат Калашникова — все пытались сделать зазоры меньше, чтобы препятствовать попаданию внутрь всякой шняги типа песка и воды, а чел сделал наоборот — чтобы песок и вода спокойно вываливались наружу и ничему не вредили), но тут явно не этот случай. Хотя вариант с часами — хорошая попытка, но все-таки нет, а значит фэйл — в очередной раз по вине программиста спутник упал, поезда столкнулись )
Такие задачи иногда подбрасываю разработчикам для расширения сознания с тегом «а слабо не гугля»?
Честно говоря, не нравятся обе ваши картинки. На мой взгляд, такого допускать не стоит ни в какой системе.
И то, в какой ветке было сделано какое-то изменение не имеет смысла. Имеет смысл то, в какой ветке есть это изменение, а в каких — нет.
Есть ощущение, что Mercurial круче и гибче, но из поста так и не смог вкурить чем же именно.
Как это часто бывает, пересев с Svn на Git испытал чувство экстаза. Все, что работало плохо и часто ломалось в Svn в Git просто великолепно реализовано. И сам процесс разработки с переездом на Git сразу сдвинулся с места. Конечно, ограничения ощущаешь лишь со временем, но до сих пор Git позволяет мне вести процесс разработки так, как мне нужно и удобно.
Возможно так и надо подходить к вопросу — если встают непреодолимые препятствия или существенные ограничения, то да, пора «менять кобылу». Но пока она везет и достаточно резво, какой резон пересаживаться на другую? Мне кажется в этом основная причина того, что Git — мэйнстрим. Он достаточно хорош, чтобы его использовать, а его ограничения не настолько критичны, чтобы переводить с него процесс на mercurial, в котором, кончено же, со временем тоже почувствуются свои ограничения.
Git очень гибок и в этом его минус, если не умеешь им пользоваться. Он дает огромное количество инструментов и надо их изучать.
Сейчас наш workflow построен так, что я точно знаю, где и когда было сделано то или иное изменение и когда оно выйдет в свет.
История проста и понятна и по ней я могу точно сказать, где именно был сделан тот или иной коммит и когда он попал в ту или иную ветку. Это видно по истории. Это в git решается не на уровне самой системы, а на уровне организации процесса. По крайней мере, у меня так.
А у вас как-то совсем далеко от идеала.
Фрилансим понравился. Очень простой и достаточно удобный. Вы молодцы, другого и не ожидал, если честно.
Сырости не заметил. Если это бета, то просто супер.
Из замечаний — если при редактировании профиля ввести ссылку на сайт и не заполнить несколько полей, то при вводе значений из сайта вырезается http:// и при повторном сохранении выдает ошибку про некорректно заполенное поле.
Немного пугает, потому, что адрес написан нормально, а выдает ошибку.
Если туда снова дописать http://, то уже сохраняется без ошибки.
И лучше сделать совсем без http:// а при сохранении уже разбирать — пришло оно или нет.
Многое пересекается. Даже «инициалы», в свое время )
Лес абстракций или голый код — зависит от задачи. Иногда нужно быстро и на раз — сделал/сдал, а иногда поднять большую систему, зная, что тебе же её придется, поддерживать и развивать. Тогда и паккаджи/абстракции/прототипы/конфиги/тесты/ и куча еще всего скучного.
В общем, по задаче.
Так же, как и Майкрософт — айпад, у них он был, если не ошибаюсь, за 4 года до эппловского, но, конечно, совершенно без понимания для чего он нужен и как он должен работать. Как впрочем и много еще чего :)
Иногда складывается ощущение, что пока крупные игроки планируют молодые хватаются за идею и делают её.
(математик по образованию, программист по профессии)
Направление хорошее, по дизайну немного не дотянули, имхо.
Плюс сейчас надо активно пробиваться — расталкивать конкурентов — этого у рамблера не видно. А так далеко не уедешь.