How to become an author
  • All streams
  • Development
  • Administrating
  • Design
  • Management
  • Marketing
  • PopSci
Log in Sign up
18.9
Karma
0.0
Rating
4
Followers
9
Following

Лобач Олег bladeofsteel

User

Profile

Posts 7

Comments 117

Bookmarks 199

  • Асинхронный PHP и история одного велосипеда
    38
    bladeofsteel
    May 18, 2019 at 08:17 PM
    0
    угу, банни — то еще поделие
  • Новый комплект для Star Citizen обойдется в $27 тысяч
    70
    bladeofsteel
    May 30, 2018 at 04:53 PM
    0
    Я к тому, что они тратят на разработку не деньги издателя, а деньги «бейкеров». И все эти покупки это вклад пользователя в «игру мечты». И пользователи готовы платить за это.


    Какая разница чьи это деньги? Ну они выбрали такую модель монетизации проекта: брать деньги с БУДУЩИХ игроков. Вполне себе нормальная модель монетизации. Судя по цифрам — ничуть не хуже модели с инвесторами.
    Но от того, что деньги они получают с конечных пользователей ДО выпуска продукта, это не перестает быть монетизацией
  • Новый комплект для Star Citizen обойдется в $27 тысяч
    70
    bladeofsteel
    May 30, 2018 at 11:16 AM
    +2
    «Монетизация» !== «pay-to-win». Монетизация — это модель получения денег. И «нагиб за бабло», и «за бабло только бесполезные (но миленькие) рюшечки», и все промежуточные варианты — это все монетизация
  • Книга «Hello World! Занимательное программирование»
    19
    bladeofsteel
    February 3, 2016 at 03:44 PM
    0
    жаль :(
  • Книга «Hello World! Занимательное программирование»
    19
    bladeofsteel
    February 3, 2016 at 03:10 PM
    0
    epub не будет?
  • Разработка системы синхронизации в реальном времени с использованием SockJS, Django, Tornado и ZeroMQ
    20
    bladeofsteel
    May 30, 2013 at 12:08 PM
    0
    А в чем проблема?
  • Стартап-ловушка
    114
    bladeofsteel
    April 6, 2013 at 12:34 PM
    0
    Использует ли он двойную бухгалтерию?

    Допускаю, что в российских реалиях это корректно, но уверен, что Дядюшка Боб имел в виду двойную запись, а не двойную бухгалтерию :)
  • «Майкрософт» сменил поставщика модуля проверки правописания для «Офиса-2013» (зря)
    105
    bladeofsteel
    February 21, 2013 at 12:40 PM
    0
    Над ссылкой на инструкцию
  • «Майкрософт» сменил поставщика модуля проверки правописания для «Офиса-2013» (зря)
    105
    bladeofsteel
    February 21, 2013 at 11:57 AM
    0
    О! Можно бесплатно получить ОРФО за отчет о работе плагина для Libre\Open Office. Но только для виндовой версии офиса :(

    Если кому интересно, инструкции по установке и отчету можно тут посмотреть: www.informatic.ru/libre-beta
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 09:18 PM
    +1
    Так, вроде, никто про линейную историю не говорил
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 05:57 PM
    0
    Что попало в мастер из него не выпиливается. Появилась проблема — делай фикс
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 05:56 PM
    0
    git diff делает точно так же — смотрим различия между ветками целиком
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 05:42 PM
    +1
    Команда у нас действительно не большая, но над одной задачей бывает работают несколько разработчиков.

    О таких калечащих изменениях обычно сообщается всем и заранее. Все приблизительно в курсе, кто чем занимается, поэтому если есть необходимость что-то поменять, то об этом сообщают людям, которых это может затронуть.

    Не понятно, чем в данном случае ребейз от мержа будет отличаться? Только тем, что семантический конфликт будет зарыт внутри мерж-комита, а не идти отдельным?
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 05:20 PM
    0
    за полтора года работы по такой схеме не было ни одного такого комита. Видимо нам везет. Или что-то делаем не так ;)
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 05:01 PM
    0
    Они будут не меньше, а все те же 1..N на каждый конфликтный файл.

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

    Похоже, что у нас слишком разный паттерн использования гита и продолжать спор смысла нет
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 04:55 PM
    0
    Вот именно, ситуация когда разработчик не знает как правильно решить конфликт бывает гораздо реже (голова у тимлида не резиновая, тут Вы верно заметили).
    Для решения конфликта тимлид наверняка привлечет разработчика ветки. Так почему бы разработчику самому не решать конфликты, без привлечения тимлида?
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 04:51 PM
    0
    Слияние отложенной фичи может быть весьма проблематичным
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 04:49 PM
    0
    Описываемая Вами ситуация для нашей команды экстраординарная (если для Вас это норма — искренне Вам сочувствую). Поэтому накладные расходы на повторный ребейз и ревью не нами учитываются (к тому же они весьма вероятно будут значительно меньше).
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 03:50 PM
    0
    Решать надо.

    Не знаю как у Вас построен процесс, а у нас в мастер вливает только тимлид. Владелец ветки перед передачей на слияние ребейзит ветку от мастера и решает конфликты, если они есть. Тимлиду же остается только влить изменения (после ревью). Конфликт решить проще разработчику, нежели тимлиду.
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 03:42 PM
    0
    когда одновременно есть десяток-два веток становится сложно в этом ориентироваться. И не всегда все ветки вливаются в мастер, периодически фичи вливаются в фичи, особенно если над одной большой задачей работает несколько разработчиков.
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 03:40 PM
    0
    Пожалуй, да — так можно прочитать
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 03:37 PM
    0
    Но, по большому счету, основной смысл в ребейзе — поддерживать порядок в графе ревизий.
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 03:35 PM
    0
    Если Вы отребейзили фиче-ветку от мастера, то она вливается в мастер без конфликтов. Я писал об этом
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 03:29 PM
    0
    вы будете разрешать для этого файла >=N раз

    Почему больше N? Разве не 1..N?
    Действительно, может оказаться так, что конфликты в одном и том же месте придется разрешать несколько раз. Но есть большая вероятность, что они окажутся проще, чем при merge.
  • Git Rebase: руководство по использованию
    169
    bladeofsteel
    December 6, 2012 at 03:11 PM
    0
    Что бы сливаться без конфликтов, простым FF
  • Использование Zend_Form_Element_File в CRUD
    13
    bladeofsteel
    February 7, 2012 at 01:12 PM
    0
    А если при комите произойдет ошибка и транзакция откатится? Файл то уже того… удален, а данные в БД остались
  • Использование Zend_Form_Element_File в CRUD
    13
    bladeofsteel
    February 7, 2012 at 12:33 PM
    0
    Э… а как Вы файловые операции в транзакцию БД завернете?
  • Zend Framework 2 — долгожданные усовершенствования в Controller и View
    59
    bladeofsteel
    January 7, 2012 at 03:49 AM
    0
    ВЗять те же бандлы… Они намного менее привязаны к конкретному проекту, чем что либо в Зенде.

    Модули ZF2 смотрели? Теже бандлы. Можно реализовать специфическую для проекта функциональность, а можно решать общую задачу (уже появилась куча модулей этим занимающихся, например, реализация регистрации/авторизации пользователей)
  • Zend Framework 2 — долгожданные усовершенствования в Controller и View
    59
    bladeofsteel
    January 7, 2012 at 12:01 AM
    +1
    Вы не так поняли комент Davert-а. Он говорит о том, что есть уже симфони2 с Di, а зендовцы свой изобрели. И говоря о двух одинаковых фреймворках под разными брендами, он имеет в виду Symfony2 и ZF2, а не ZF1/ZF2
  • Zend Framework 2 — долгожданные усовершенствования в Controller и View
    59
    bladeofsteel
    January 6, 2012 at 11:26 PM
    0
    Ну, есть они не только в Symfony2, и не в ней первой появились. Так что, видимо, и у симфонистов тоже были причины «изобретать велосипед»

    > Ну честно, если бы добавили новые компоненты, или какие-то интересные архитектурные решения…

    Хм… архитектуру ZF практически полностью переписали, Вам этого мало?! :)
  • Zend Framework 2 — долгожданные усовершенствования в Controller и View
    59
    bladeofsteel
    January 6, 2012 at 10:55 PM
    +2
    По мне так самым вкусным в ZF2 стали DI и Events
  • Советы по фиксациям в SVN
    60
    bladeofsteel
    August 31, 2011 at 11:52 AM
    0
    Хм… так есть же ссылка
  • Собираем виртуалку с phpdaemon'ном на Ubuntu 10.10
    11
    bladeofsteel
    June 16, 2011 at 05:57 PM
    0
    параметр конфига сборки runkit-а должен быть не --enable-modify, а --enable-runkit-modify (видимо изменился с момента публикации)

    И скрипт запуска демона теперь переименован — /opt/phpdaemon/phpd
  • Возможности MongoDB
    90
    bladeofsteel
    May 21, 2011 at 08:56 PM
    0
    Арбитр рекомендуют ставить не параллельно со слейвом, а на сервере с приложением.

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

    У нас схема с арбитром вполне работает, но я поэкспериментирую ещё с 3-full-node схемой
  • Возможности MongoDB
    90
    bladeofsteel
    May 21, 2011 at 07:24 PM
    0
    Этот пример вполне себе работает до определенного момента. И обычно критичным становится не ресурсы на вставку, а время преобразования при выводе.

    И вообще, этот пример приводится скорее как иллюстрация отличия монги от реляционных СУБД, а не прямой призыв к действию. При проектировании надо головой пользоваться, а не оголтело пользоваться примерами
  • Возможности MongoDB
    90
    bladeofsteel
    May 21, 2011 at 06:35 PM
    0
    Ясно, спс
  • Возможности MongoDB
    90
    bladeofsteel
    May 21, 2011 at 06:34 PM
    0
    Ну если у Вас нагрузка НАСТОЛЬКО высока, что Вы оптимизируете вставку в поддокументы, используйте одноуровневые документы, там накладные расходы меньше
  • Возможности MongoDB
    90
    bladeofsteel
    May 21, 2011 at 06:31 PM
    0
    Используйте плоскую структуру, если вставка элемента в поддокумент занимает критично много ресурсов
  • Возможности MongoDB
    90
    bladeofsteel
    May 21, 2011 at 06:13 PM
    0
    У Вас настолько большая нагрузка, что приходится задумываться о способе сохранения сервером данных?
  • Возможности MongoDB
    90
    bladeofsteel
    May 21, 2011 at 06:11 PM
    0
    а платформа какая? и драйвер?
  • ← here
  • there →
  • 1
  • 2
  • 3

Info

  • Rating 6,028–th
  • Date of birth March 11, 1978
  • Activity 3/24/20, 10:43 AM
  • Registered January 25, 2008

Contribution to hubs

  • Version control systems 26.4
  • Zend Framework 4.6

Your account

  • Log in
  • Sign up

Sections

  • Posts
  • Hubs
  • Companies
  • Users
  • Sandbox

Info

  • How it works
  • For Authors
  • For Companies
  • Documents
  • Agreement
  • Terms of service

Services

  • Ads
  • Subscription plans
  • Content
  • Seminars
  • Megaprojects
© 2006 – 2021 «Habr»
Language settings
About
Support
Mobile version
Language settings
Interface
Content