Абсолютно верно. Решали похожую задачу по хранению даты с таймзоной в базе (вообще думал что она распространенная и не должна вызывать сложностей). Вкратце: делим всю дату на 2 части, первая часть timestamp типа long, вторая часовой пояс (буквенное выражение или отклонение в часах, в зависимости от задачи). На клиент возвращается объект из двух частей и строится нужная дата со смещением.
Т.е. получается что со спутником не получится иметь постоянную связь? А как планируется поступать в случае нештатных ситуаций, требующих оперативного вмешательства? Жалко все таки потерять спутник только потому что с ним вовремя не вышли на связь и не подкорректировали орбиту…
Возможно я глупые вопросы задаю и на это есть банальный ответ, но уж простите, я далек от реальности в этой стезе.
Скажите, а как планируется следить за спутником во время его функционирования? Ну т.е. в реальной жизни (я так предполагаю) за всем этим оборудованием следят 24х7 на весь срок жизни аппарата. Вы планируете создавать свой ЦУП? :)
В целом, Вы правы, но свой бизнес это всегда риск. Поскольку я не был в Вашей шкуре, мне сложно судить об этом хладнокровно. Тем не менее, меня учили действовать так и я бы в любом случае эти принципы стремился соблюдать :)
Все-таки я не согласен. Даже если Вы никогда не занимались такой деятельностью, можно разбить проблему на составные части и измерить каждую из них.
В примере про коммерческие предложения (которых, к слову, я тоже никогда не составлял):
— у меня команда 4 человека, т.е. это 1 крупный проект, 2 средних проекта или 4 небольших. Примем опыт и квалификацию всех специалистов как равную (для примера и упрощения).
— мои целевые месячные показатели прибыли 100 т.р. начиная с 2017 года
— моя стратегическая цель зарабатывать более 1200 т.р. в год, начиная с 2018 года
От этих целей можно начать постановку конкретных задач. Например, для успешного функционирования необходимо рассылать коммерческие предложения на сумму 200 т.р. ежемесячно. Из них необходимо добиться заключения контракта у _введите_свой_процент_из_открытых_данных_ потенциальных заказчиков (статистика успешных заключений сделок).
Таким образом, Вы четко расставите для себя приоритеты и будете иметь конкретные сроки для их реализации. Кстати говоря, цели со временем жизни организации нужно корректировать или менять, это совершенно нормально.
У Вас плохо сформулированы цели. Есть такая штука как SMART, очень советую обратить внимание. Если следовать этой методологии, быстрее, а главное с полным контролем, придешь к результату, проверено.
Кстати то, что вы составили в целом и есть бизнес план, просто в нем четко не выделены разделы как написано в книжках, но смысловая нагрузка точно та же.
Я видимо не до конца разобрался… Сейчас перечитал документацию и понял, что есть директива resolve и директива resolver. Получается что именно resolve (без 'r' на конце) недоступна в бесплатной версии?
Стоит наверное упомянуть, что не всё наследуется и не все директивы можно применять внутри «контейнеров». Например, директива resolver работает внутри location только в nginx+. В бесплатной версии ее необходимо вытащить на уровень server. И мне до сих пор не очень понятно, каким образом можно проверить ее работоспособность на этом уровне, без привязки к конкретному upstream… Может кто сталкивался?
Если это про площадку в обеденной зоне, то да, заглядывал и слушал. Хотя там скорее аудитория для интернет трансляций (я правильно понял, что в прямом эфире шел разговор?). Ну и для меня такие мероприятия ценны в первую очередь живым общением, поиском партнеров и сотрудничества :)
В целом то да, но вот нам удалось пройти все стойки за час перед докладами и утром второго дня «дообщаться» с теми, кому меньше уделили внимания :) Зато в середине дня в перерывах было скучновато, имхо.
Спасибо большое за конференцию, было действительно интересно.
Хотелось бы на будущее побольше стоек с разными компаниями (было бы классно привлечь побольше спонсоров) для интересных бесед между докладами.
Кстати, совсем покинутой казалась ветка для IT директоров, хотя там тоже было что послушать. Может на будущее ее перенести поближе к залам из дискуссионной зоны?
Поясните, пожалуйста, что не так с документацией по Ангуляру? Есть пошаговый гайд, есть описание для разработки директив/сервисов и есть описание API. Мне в свое время этого хватило с головой для старта.
А не расскажите, как в целом себя показал HipChat после внедрения? Удобно ли ей пользоваться для решения повседневных задач коммуникации? Сложно ли ее администрировать? Может были какие-нибудь интересные случаи?
Бред наидичайший. Тонны желчи и, видимо, личной обиды.
Вы должно быть в курсе, что бывают хорошие специалисты и плохие специалисты? Не только менеджеры, но например и программисты?
P.S. Вот даже интересно к какой группе себя отнести в этой классификации?.. Закончил кафедру менеджмента в машиностроении (привет соседнему комментатору) магистром, работаю в ИТ компании руководителем разработки. Программирование со школы было хобби, постоянно развивал и подтянул до профессии. Ушел в ИТ, потому что работать на заводе за 15 тыс.р. не хотелось от слова совсем (хотя специальность очень нравилась).
Возможно я глупые вопросы задаю и на это есть банальный ответ, но уж простите, я далек от реальности в этой стезе.
Спасибо за мысли.
В примере про коммерческие предложения (которых, к слову, я тоже никогда не составлял):
— у меня команда 4 человека, т.е. это 1 крупный проект, 2 средних проекта или 4 небольших. Примем опыт и квалификацию всех специалистов как равную (для примера и упрощения).
— мои целевые месячные показатели прибыли 100 т.р. начиная с 2017 года
— моя стратегическая цель зарабатывать более 1200 т.р. в год, начиная с 2018 года
От этих целей можно начать постановку конкретных задач. Например, для успешного функционирования необходимо рассылать коммерческие предложения на сумму 200 т.р. ежемесячно. Из них необходимо добиться заключения контракта у _введите_свой_процент_из_открытых_данных_ потенциальных заказчиков (статистика успешных заключений сделок).
Таким образом, Вы четко расставите для себя приоритеты и будете иметь конкретные сроки для их реализации. Кстати говоря, цели со временем жизни организации нужно корректировать или менять, это совершенно нормально.
Кстати то, что вы составили в целом и есть бизнес план, просто в нем четко не выделены разделы как написано в книжках, но смысловая нагрузка точно та же.
За статью спасибо, жду продолжения.
Хотелось бы на будущее побольше стоек с разными компаниями (было бы классно привлечь побольше спонсоров) для интересных бесед между докладами.
Кстати, совсем покинутой казалась ветка для IT директоров, хотя там тоже было что послушать. Может на будущее ее перенести поближе к залам из дискуссионной зоны?
Вы должно быть в курсе, что бывают хорошие специалисты и плохие специалисты? Не только менеджеры, но например и программисты?
P.S. Вот даже интересно к какой группе себя отнести в этой классификации?.. Закончил кафедру менеджмента в машиностроении (привет соседнему комментатору) магистром, работаю в ИТ компании руководителем разработки. Программирование со школы было хобби, постоянно развивал и подтянул до профессии. Ушел в ИТ, потому что работать на заводе за 15 тыс.р. не хотелось от слова совсем (хотя специальность очень нравилась).