• +1
    А я наоборот часто слышал такое высказывание среди рубистов :)
    RailsClub 2015: Интервью с Сэмом Пиппеном
  • +3
    Вы всегда можете отправить Pull Request ;)
    Туториал по Coub API
  • 0
    Не скромная такая экономия получается. И, кстати, не только на этом экономите. На днях таким образом из postgresql вытащил большой json за ~ 5 ms вместо 180 ms в случае с acts_as_api + сериализация.
    Как мы увеличили скорость генерации JSON в 6000 раз
  • +1
    git-flow как раз так и развивается. Кстати очень активно :)
    Чем плох свой Open Source проект
  • +5
    Суть была в том, чтобы некоторые фичи внедрять при материальной поддержке.


    Делайте платный саппорт. Не убивайте опенсорс.
    Чем плох свой Open Source проект
  • +1
    Так мы этим и занимаемся :))) И мы не жаловались )))
    Чем плох свой Open Source проект
  • 0
    1. По поводу коммантария, содержимое его было скорее как «Почему вы игнорируете общепринятые правила хорошего тона?». Чем плоха критика? Или нужно писать «Ой, вы кажется тут плохо написали… что если сделать вот так?» Бред!

    2. Профессионал всегад сразу поймет о чем речь идет (не упрекаю Дмитрия в непрофессионализме, его уровень весьма высок и заслуживает уважения.). Там был намек, что это должно быть не там. Давайте еще по каждому чиху будем создавать Issue. Комментирование кода на гитхабе как раз и предназначено для целей ревью кода. Замечания никогда не были приятными. Мы можем этого не делать, если это не по душе.

    3.
    image
    +
    image

    4. Мы неоднократно присылали PR содержащие рефакторинг.

    5. Мы постоянно пишем разработчикам с предложеиями о том, как можно сделать «по-другому». И часто делаем это в кулуарах. Написали в паблике — все, караул?

    6. Мы адекватно воспринимаем, когда наши решения также критикуют.

    7. Мы всегда готовы оказать посильную помощь. Об этом неоднократно сообщалось.

    В чужом глазу соринку видно, а в своём и бревна не видать.


    Парни, давайте не будем жаловаться на жизнь. Мужики собрались ведь.

    Оперсорс хорош тем, что делает вас еще более крутыми спецами. Не смоотря на то, насколько круты вы сейчас.
    Чем плох свой Open Source проект
  • +2
    Я тоже видел этот комментарий. И мне кажется вы не проникли сутью проблемы, ибо такие вещи просто так не исправить.

    Нельзя просто так взять и перелопатить ключевые модели. Автор комментария выразил свой «шок», по поводу того, как такое можно было допустить изначально. И, кстати, польза в этом комментарии очень большая.

    Да, Дмитрию было не приятно его читать, но, уверен, в будущем он не будет допускать таких промашек. Никто не идеален и все прекрасно это понимают, однако это не значит что не нужно критиковать код друг друга.
    Чем плох свой Open Source проект
  • +4
    Большинство опенсорс проектов родились по прнципу «сделал себе, поделился с сообществом».

    Если разработчик отвественный, то в случае отсуствия интереса к проекту он может, например, расшарить права на него активному разработчику, который хочет его развивать, или делегировать вообще репозиторий.

    Вклад всегда останется в истории.
    Чем плох свой Open Source проект
  • 0
    Да, да, мне стоит поправиться, ибо не корректно выразил свою мысль. В реалиях обычно не стоит задача бекапа кода сайта :)
    Разрабатываем новый формат файла для бэкапа сайтов
  • 0
    Т.е. всякие там файлы, фотки, аватарки юзеры не заливают?

    А как обстоит дело с удаленным размещением файлов, фоток, аватарок? Или у вас не встречалось ситуации с несколькими фрондами для исполнения кода сайта?
    Разрабатываем новый формат файла для бэкапа сайтов
  • 0
    В том то и дело, что стоит задача бекапа не файлов сайта, а контента (файлы контента) и бд. Мы же технари, давай общаться с использованием соответствующей терминологии.
    Разрабатываем новый формат файла для бэкапа сайтов
  • +3
    А кто говорит, что мы так не делаем? ;)
    Релиз GitLab 4.0 и GitLab CI
  • 0
    На самом деле, есть ряд мест, которые стоит там «прилизать». Что очень радует, парни очень адекватные и правильно реагируют на критику и следят за чистотой кода.
    Релиз GitLab 4.0 и GitLab CI
  • 0
    devise хорош до момента кастомизации
    API ВКонтакте на Ruby
  • +4
    Я даже не думал с вами спорить :) надеюсь сопоставление «терминологии» окажутся полезными не только нам :)
    Техническое задание на сайт
  • 0
    Я возможно недосказал. Если я не ошибаюсь, то где-то было красиво сказано waterfall methodology is a description of the natural, and the most dangerous approach to the management of projects, but do not sew the fly's trunk (мог допустить ошибку, ибо по памяти). Другие методологии могут быть эволюционированием или комбинированием. Взглянем на тот же MSF.

    Это я к тому, что не может проект выжить без применения какой либо методологии и вполне естественно, если по дефолту будет водопад:

    . Пришел заказчик, высказал пожелания
    … Команда села, подумала
    …… Уточнили все детали
    ……… Сели делать и сделали
    ………… Сдали.

    Согласен, при малом опыте у команды — будут итерации, вполне оправданные, но, не хочу накручивать, вполне естественно, что по дефолту упоминается водопадная модель.

    К тому же, про отрицание всех методологий я не говорил. Я сразу уточнил, что речь идет именно о какой-то конкретной методологии, а не о всех сразу. Это так, если уж цепляться к словам.
    Техническое задание на сайт
  • +3
    Мечтаю попасть к тимлиду, который будет способен заранее не допустить серьезных ошибок для жизни такого проекта. К сожалению, таких очень немного…

    НО, зная несколько таких людей, могу точно утверждать, что вопрос ТЗ для них критичен и у них существует 2 версии ТЗ:
    1. Предварительное, которое, как ожидалось, размытое.
    2. Детализированное, на каждую итерацию.

    Прелесть первого в том, что можно оценить, где оставить брешь для масштабирования
    Прелесть второго — этап будет закончен в сроки, не важно стоит ли переделывать то, что было сделано ранее.

    И волокита с ТЗ ведется постоянно, на каждую итерацию. Заказчик высказывает пожелания, а они описывают это и спрашивают: «Вы так хотите?», если нет — уточняют. Пока не провалились, да я и сомневаюсь в их провале. Заказчик готов платить за то, что они думают. Он не нуждается в писанине ради отмазки, ему нужна реальная работа и он прекрасно понимает, что изменить что-то можно по-разному. Особенно это важно и критичено при ревью кода, к примеру.
    Техническое задание на сайт
  • 0
    Нет, в целом, в большинстве своем я с Вами согласен, однако я не согласен с подходом «проект маленький -> к черту методологию» (в данном случае я горю про скрам, но на его месте может стоять любая другая)

    То, что это немного «не корректно», вести много проектов одновременно — да. Все равно программист, как бы не старался, он по большей части будет выполнять их линейно и тут уже у менеджера возникают жуткие головные боли по поводу того, что проектов много, контроль терять нельзя. У вышеупомянутой методологии есть много прекрасных моментов, которые много упростили бы жизнь. Не хочу впадать в дебаты, они тут бессмысленны, но ответьте себе на простой вопрос: 'вы часто на 100% следуете предписаниям методологии, не совершая каких либо отклонений, не подмешивая в процесс «лучшие практики» из других процессов?'. Никто не сказал, что нужно принципиально выдерживать все предписания в полном виде. Очевидно, что некоторые этапы возьмутся наскоком и вполне успешно, однако и в «маленьких» проектах бывают подводные камни, как это и не смешно звучит.

    По поводу 10 сайтов визиток параллельно — не вопрос. Костяк все равно будет один и тот же (±) и время, затраченное, к примеру, дизайнером и верстальщиком заведомо больше, чем затратит программист. И вот тут как раз и возникает не состыковка сроков, однако, это уже совсем другая тема, не из области ТЗ.
    Техническое задание на сайт
  • 0
    Интересно, что именно вы относите к понятию маленький проект? И как переформулируете высказывание, если этих проектов 5, 10, 20 параллельно…
    Техническое задание на сайт
  • +15
    Вот спасибо! Честное слово, безумно хорошо и доходчиво для определенного круга лиц написано. Надеюсь, что те, кому я ссылку дал впитают информацию и больше не будут допускать ошибок, совершаемых ранее.
    Техническое задание на сайт
  • 0
    Плюсом в сторону Zabbix'а будет еще и возможность написания собственных скриптов и триггеров ;)
    Методы мониторинга веб-сайтов и сервисов
  • 0
    Угу. Сплошным потоком, ато вдруг точка с места сдвинется :)
    Владельцам Wi-Fi оборудования вменяют обязанность ГЛОНАССирования
  • +3
    Как же меня бесит, когда пользователь плачется на минусовку кармы. Что ж никто не пишет «О да! Спасибо что вручили мне 100 плюсов в карму»?

    Сформулировал свою мысль, написал? Ляпнул глупость — получи гранату. Общественное мнение есть общественное мнение. Каждый из нас — часть этого общества и не за чем из него выгораживаться.

    З.Ы.

    Ну не удержался :)
    Владельцам Wi-Fi оборудования вменяют обязанность ГЛОНАССирования
  • 0
    Кто их знает… Запустят механизм стукачества среди безработных и бабуль и плакало наше комфортабельное отсутствие проводов в квартире…
    Владельцам Wi-Fi оборудования вменяют обязанность ГЛОНАССирования
  • 0
    Однако, сама формулировка не только отвлекает, но и кидает в ступор…
    Не отвлекайте пользователя зря
  • +1
    вот затяжного переписывания разработчики как раз и постарались избежать… Тем самым самые частые и острые модули. а не те, что ради забавы били написаны, считайте что готовы и в день релиза — через пару дней будут вполне рабочими.
    Долгожданный RC Drupal 7
  • 0
    Можно! Я сам до потолка прыгал, когда реализовал. Там все просто чики-поки ))) Другого выражения то и не подберешь ;)
    Долгожданный RC Drupal 7
  • 0
    Например реализация пошаговых форм, в которых одно поле обязательно зависит от другого и если не выполняется ряд условий — не доступно к заполнению. На шестерке — самоубиство, семерка — в ядре поддерживает…
    Долгожданный RC Drupal 7
  • 0
    Само замечательное, что ИЛИ КАК.
    Долгожданный RC Drupal 7
  • 0
    Ну насчет перевода — на друпалере есть вполне сносный, а при помощи еще одного модуля можно легко допритесать его. Этап уже пройденный.

    По поводу модулей — если самому не лень писать — то да, ждать придется, но могу отметить, что в отличии от 6-ки — под семеркой программировать одно удовольствие! А множество модулей хоть и в деве — но вполне рабочие.

    Ну и по поводу перехода с 5-ки на семерку — переход освящен: 5 -> 6 -> 7… В инструкциях это четко обозначено. Вот проблема переноса информации из 5 -> 6 предо мной не вставала. с 6-ки на 7-ку относительно без геммороя перешел. В общем потихоньку жизнь налаживается.
    Долгожданный RC Drupal 7
  • 0
    А я скрепя зубами запускался на семерках. И ни капли не жалею. Наоборот — рад. Лучше апи выучил )
    Долгожданный RC Drupal 7
  • 0
    Мммм. Хорошо если так =) А может вопрос в поставках?
    Обзор андроидофона HTC Desire HD: Голодный гигант
  • +1
    А зачем вам тогда ТЕЛЕФОН? :)
    Обзор андроидофона HTC Desire HD: Голодный гигант
  • Комментарий из публикации, перенесённой в черновики.
  • 0
    Если бы зарядки хватало на 1 день минимум — это не было бы проблемой…
    Обзор андроидофона HTC Desire HD: Голодный гигант
  • +2
    Да спору нет, аппарат то хороший, но риск попасть в нелепую ситуацию довольно высок. Ладно если большая часть времени проходит в офисе, где можно прокинуть зарядку и наслаждаться… А если нет…
    Вообще — по поводу доработок: как-то дорабатывал свою старую добрую Toshiba G900, установив динамическую скорость проца (не работает — частота работы на минимуме, работает — повышается). Не могу сказать что драйвера были вах какие классные, но довольно сильно помогало (правда иногда были жуткие тормоза из-за того, что аппарат «не успевал» разогнаться). Время работы возросло значительно :) Но покупать этот агрегат, чтобы на нем так (ну или подобным образом) издеваться — извините.
    Обзор андроидофона HTC Desire HD: Голодный гигант
  • 0
    Да вот у меня лично реальная проблема в том, что я не могу в течении дня спокойно подзарядить телефон (ни машины нет, ни сижу часто на одном месте), а уйдя из дома в 7 утра могу вернуться 2 часа ночи, притом на связи постоянно. Ну как тут с восьмичасовым зарядом? Я со своим то сейчас мучаюсь, хотя он у меня часов 10 держит… Но все равно проблема…
    Обзор андроидофона HTC Desire HD: Голодный гигант