1. Все сервера линуксовые, на ext3, поверх реализована распределенная файловая система. Сохранность обеспечивается N,K алгоритмом, правильно соотношение N,K постоянно автоматически контролируется. В случае утери одной части сразу же запускается алгоритм регенерации. Могу привести пример, довольно давно мы закупили жесткие диски зеленой линии WD, и довольно большой процент их них пришел в негодность за короткий промежуток времени. Так вот, пользовательские данные не были потеряны.
2,3 Тут шифрование на стороне клиента, шифрование протокола, внутренние правила определения прав доступа. Не уверен, что в праве детально это описывать в открытом источнике.
4. В штатах и европе и подчиняются юрисдикциям стран размещения, конечно. Случаев обращения пока не было. Обязаны ли мы сообщать? Такие вопросы регулируются законодательно, мы тут не можем пойти наперекор законам соответствующих стран.
Так на вскидку сложно сказать сейчас, было довольно много исправлений, вероятно это тоже поправили. Я попросил проверить на всякий случай, отпишусь как будут результаты.
одно дело рекламные бодания и другое дело действовать в ущерб пользователям. и потом логика «я буду действовать подло, потому что они тоже действуют подло» не может служить оправданием.
хм, давайте попробую с другой стороны объяснить свою точку зрения. такие мелкие пакости не делаются когда в датском королевстве все хорошо. не то чтобы там плохо, но опасности все же есть и со стороны самсунга и со стороны мс той же. а раз есть опасения подталкивающие к таким выходкам, то будут и еще ходы и будет вторая тысяча гиков и так далее… ну поживем — увидим.
вряд ли этот «профит» будет длиться вечно, рано или поздно они договорятся. а вот осадок останется надолго. раньше гугл воспринимался корпорацией добра, сейчас уже не так давно. впрочем оно, видимо, всегда у них так, МС тоже долго с экплорером носилась в свое время…
да, страх довольно действенный способ мотивации… например такое клише, только в армии можно зимой ночью в мурманске отправить новобранцев искать бананы — и найдут. мотивация? да. эффективно? да.
для меня важно утро, как его начнешь так и попрет далее. потому утром важно прийти пораньше, потом что народу мало, совещаний нет и можно спокойно сделать пару тройку самых важных и сложных задач. середину дня я уже сдался отстаивать и отдал на откуп совещаниям…
а так некоторые советы из статьи не очень применимы к тем, кто много взаимодействует…
А как оценить какой труд сколько стоит? И как привлечь инвестиции в новые технологии, которые не факт что выстрелят? Да много вопросов вообще возникает…
Мда, с одной стороны конечно одно, с другой стороны работаешь в софтверной компании и порядочно там напрягаешься… И как провести справедливую грань между теми кто создает и теми кто потребляет…
При всем уважении, вы несколько наивны, бывает, что люди не уговариваются…
Неужели вы думаете, что мы его молча отпустили и не пытались отговорить? Он у нас вообще лет 6 проработал, то есть мы его ценили и сейчас ценим. Так что давайте признаем все же, что вешать всех собак на манагера не справедливо и будем спать :) я в данном кейсе как манагер манагера не обвинял оного в том, что он упустил девелопера и, думаю, что поступил справедливо. Доброй ночи…
отчасти соглашусь. но замечу, что у менеджера не цель выстраивать общение с разработчиком, это лишь способ достичь результата. отсюда и другие способы достичь оного, например заменить уж очень замкнутый объект класса Девелопер. Случай был, девелопер не хотел проходить ревью перед коммитом в чужую библиотеку и поставил условие, что мол отменяйте для меня ревью, а не то уволюсь. И был уволен. сейчас назад просится, но вакансии уже нет. Так что парни, при всем уважении, не зарывайтесь, компромисс, это когда он с обоих сторон.
вам стоит устроиться в два клика в организацию первого типа, там эджайлом вас не побеспокоят и вы сможете реализоваться как «профессионал» в бесконечном ватерфоле…
в таком случае, наверное, глупо называть раздражающими запросы по поводу стоимости задачи от класса Manager? на то он и объект класса Manager, что стремится измерить все в часах-днях(читай деньгах).
ответ на ремарку не шутку: Да, должен, но он так же должен понимать в какого рода конторе он работает:
1. например гос учреждение, пишут что-то для себя, деньги получают независимо от результата.
2. контора продающая софт, который пишет(Parallel, Kaspersky, Acronis).
глупо приходить в контору номер два и раздражаться от того, что с вас спрашивают сроки завершения задачи. Или что требования порой меняются(такое бывает, это жизнь). Наверное, вполне очевидно какая будет обстановка в конторе номер 1 и номер 2? и может разумно устроиться в контору номер 1 и жить себе спокойно? так что, как ни крути, но если объект класса Developer, не способен взаимодействовать с объектом класса Manager(в том числе выдавать сроки и следовать им), то в этой связке один из объектов надо менять.
п.с. вторая подобная статья на хабре за последнее время, но вроде взрослые люди пишут и это удивительно. Вообще лирическое, но мне кажется есть такая опасность для девелопера утратить связь с реальным миром и сильно переоценить себя. Некая локальная звездная болезнь. Не подумайте только, что я такой гуру высокомерный, но случаи правда были и карьера людей слегка ломалась в такие моменты…
2,3 Тут шифрование на стороне клиента, шифрование протокола, внутренние правила определения прав доступа. Не уверен, что в праве детально это описывать в открытом источнике.
4. В штатах и европе и подчиняются юрисдикциям стран размещения, конечно. Случаев обращения пока не было. Обязаны ли мы сообщать? Такие вопросы регулируются законодательно, мы тут не можем пойти наперекор законам соответствующих стран.
это вы минусами подкрепляете свои аргументы что ли? :D
ладно, удачи вам, я пойду…
Пусть земля будет ему пухом
но зачем так жить? =)
а так некоторые советы из статьи не очень применимы к тем, кто много взаимодействует…
Неужели вы думаете, что мы его молча отпустили и не пытались отговорить? Он у нас вообще лет 6 проработал, то есть мы его ценили и сейчас ценим. Так что давайте признаем все же, что вешать всех собак на манагера не справедливо и будем спать :) я в данном кейсе как манагер манагера не обвинял оного в том, что он упустил девелопера и, думаю, что поступил справедливо. Доброй ночи…
ответ на ремарку не шутку: Да, должен, но он так же должен понимать в какого рода конторе он работает:
1. например гос учреждение, пишут что-то для себя, деньги получают независимо от результата.
2. контора продающая софт, который пишет(Parallel, Kaspersky, Acronis).
глупо приходить в контору номер два и раздражаться от того, что с вас спрашивают сроки завершения задачи. Или что требования порой меняются(такое бывает, это жизнь). Наверное, вполне очевидно какая будет обстановка в конторе номер 1 и номер 2? и может разумно устроиться в контору номер 1 и жить себе спокойно? так что, как ни крути, но если объект класса Developer, не способен взаимодействовать с объектом класса Manager(в том числе выдавать сроки и следовать им), то в этой связке один из объектов надо менять.
п.с. вторая подобная статья на хабре за последнее время, но вроде взрослые люди пишут и это удивительно. Вообще лирическое, но мне кажется есть такая опасность для девелопера утратить связь с реальным миром и сильно переоценить себя. Некая локальная звездная болезнь. Не подумайте только, что я такой гуру высокомерный, но случаи правда были и карьера людей слегка ломалась в такие моменты…