Philipp

На практике agile выглядит так: после планирования разрабы вежливо выпроваживают бизнес за дверь и начинают писать код. Он им нужен исключительно чтобы бизнес не подкидывал новые гениальные сверхсрочные хотелки, а так-то любой девелопер за исключением совсем уж новичков может организовать себя.

Бизнес думает, что agile ему нужен для контроля, но на самом деле он нужен для -понимания, что нельзя получить все сразу и уже вчера- расстановки приоритетов, котов пасти все равно невозможно.

Думаю лучшая вот:

symfony.com/blog/new-in-symfony-3-1-cache-component

Компонент уже готов к PSR-6

u>>=1 - u = Math.floor(u / 2).
u&1 - u % 2.
u<1<<c - u < Math.pow(2, c).

Когда Вам потребуются Оки, Вы пополняйте баланс, с учетом того что у Вас в Оках он отрицательный, по факту выйдет что вы оплатили услугу и не получили ее. С этого момента Вы можете написать претензию на ненадлежащее исполнение услуг, и приложить квитанцию об оплате. Тем самым Вы переведете ваши финансовые отношения с ОК в правовую плоскость, и уже юристы Ок будут стучать по голове программистам а те в свою очередь решать проблемы с отрицательным балансом, в довесок можете припомнить прошлую проблему с отрицательным балансом.
Отправляйте обычной почтой с уведомлением о в вручении.

Ну, сами подумайте, что бы вы ответили человеку, который заявляет: хочу промышленную СХД с обвязкой (коммутаторы) и дисками собрать на коленке, бюджет на всё в миллион рублей (~17000$).

Тут уж, дорогой друг, либо коленки, либо промышленная СХД (особенно учитывая хотелки в виде тиринга, дедупликации, снапшотов и прочего).

1) SATA-диски под большой нагрузкой будут грешить silent errors (т.е. искажениями данных, которые никто не заметит, пока не будет поздно (например, при ребилде массива). Поэтому софт должен будет уметь эти ошибки выявлять в оффлайне (как scrub в ZFS или background device scanner у ScaleIO).

2) Цены на "деревянные" (что бы это не означало) СХД в интернетах таки есть. Например, тут: stss.ru/products.html

3) Если собираетесь покупать ScaleIO, то там адекватных денег не ждите. Запрашивали несколько месяцев назад цены -- 44k$ за 50 Тб СЫРОЙ ёмкости. Когда соберёте массив на 4-х нодах, получите меньше 20 Тб реальной ёмкости. ScaleIO можно юзать и за так, но про поддержку забудьте. Если у вас реально суровый прод, то без поддержки -- это искать прилючения на свои нижне-задне-спинные мышцы.

4) Дедупликация-то вам нахрена? Учитывая массив данных, который вы собираетесь там хранить (документы/фотки/видео), профит от дедупликации будет чуть меньше, чем никакого, а вот нагрузка на память и потенциальные глюки будут ого-го.

Есть вот такой проект где можно найти себе место в open source

Соберите статистику по таким оценкам и в удобный момент покажите график на сколько процентов ошибались.

А вообще есть книги по таким оценкам. Цитаты по теме

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

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

Рецепт для битрикса.

В игнор:

/bitrix
/upload

Шаблоны и компоненты выносите в папку /local.

Верстку для шаблона располагаете в его папке, игнорите все что собираете.
В том числе игнорите обязательный styles.css, в который собираете стили.

Выглядеть будет вот так:

договаривайся на то чтобы поработать почасово. в свободное от нынешней работы время. к примеру на 2 недели. чтобы понять все ли устраивает и работодателя и тебя. нормальные работодатели спокойно на такое идут. потому что им самим это нужно тоже. ну и вот так работаешь после своей нынешней работы пару недель, если все нравится - увольняешься и устраиваешься.

Разбейте проект по модулям(в зависимости от симантики сущностей), в каждом модуле пусть будет своя папка с сервисами. Так будет больше порядка и удобнее работать. На взаимоотношения с одной сущностью создавайте один сервис.

Или выносите в отдельную папку каждый компонент, а в неё уже и сервис, который он использует, но в таком подходе есть вероятность дубликации сервисов(случайно)

Нативным мобильным приложениям, использующим SDK Facebook, будут предоставлены долгосрочные маркеры доступа, действующие около 60 дней. Эти маркеры будут обновляться ежедневно, когда пользователь приложения отправляет запрос на серверы Facebook. При отсутствии запросов срок действия маркера истечет приблизительно через 60 дней, и для того чтобы получить новый маркер, придется снова выполнить процесс входа.
Вот прямо из документации:
https://developers.facebook.com/docs/facebook-logi...

есили нода и сокеты страшный сон, то ангуляр реат и метеор будут просто кошмар )

https://www.google.com.ua/search?q=wiki+end+to+end...

Почитайте про SOLID. DRY и KISS.
Применяйте их к своему коду.
Небольшой трюк: код далеко не всегда и не у всех сразу родится красивым, обычно его рефакторят, при этом вовсе не обязательно получать неописуемую красоту, достаточно, чтобы получилось "нормально"