Предположим, я не знаю английского, но как бизнес отчитываюсь на русском в собственной стране. Мне как бизнесу глубоко и далеко наплевать на то, что покупатель оказывается из, не знаю, Чада, где местный диктатор ввел обязательные чеки на чадском и отчеты в чадскую налоговую на этом же языке. В противном случае у меня с какого-то перепуга возникает аш обязанность нанимать переводчиков на всех языках мира, что нонсенс
.
В «старой» версии это очевидное казалось бы противоречие прописано черным-по-белому. А откуда вылез этот бред?
Это не говоря уже о физической невозможности выяснить месторасположение клиента. А если он со своей итальянской картой находится в Чаде, а платит через сервер компании в Гонконге, которые расположены сами по себе в штатах? Тут как бы, ну, очевидные вопросы-то… И конечно, закон никак не поддерживается (определение местоположения клиента) нашими родными плат сервисами с машинками для чеков в датацентре какого-нить южного чертанова, те если п и хотел бы внезапно платить, да техницки никак…
мне наш админ говорил что заббикс умеет типа чаще мониторить, но на практике у меня получилось вот что:
— графики кактуса более понятны для меня и еще пары человек на проекте. по цветам, по интерполяции данных. в целом это самое кардинальное для меня отличие тк в заббиксе я вообще ничего не понимаю. админ который нам поставил заббикс сказал что он вообще в графиках ничего не видит :) почему — стало потом понятно :)
— заббикс по дефолту (!) умеет чаще опрашивать свои щупы, но при желании можно и кактус так настроить. в целом мне ни разу не понадобилась такая более частая статистика
— у заббикса другая система организации графиков. кактус мне лично больше нравится с древовидной структурой серверов
— заббикс сильнее грузит тачки чем кактус, те в топе на нагруженных машинках я его периодически вижу. кактус — ни разу
не знаю насколько это рекорд, но с однокурсником приходили на лабораторные по паскалю стабильно пьяненькие, примерно в таком же состоянии в середине где-то семестра я пытался договориться о сдаче зачета (программы были конечно уже все сданы) досрочно.
отказали. вобщем досрочно и за такой срок у меня так больше ни с одним предметом не получалось :)
— видел вживую на серверах LA>1000, причем сервак еще отзывался
— коллега видел >1300, тоже отзывался
— когда-то один из написанных проектов примерно полчаса держал трафик от дигга в одном из разделов после попадания в топ :) сейчас другой уже держит больше, но на дигге так больше в топ не вставали
— как-то в процессе работы проекта выяснил, что есть мегабольшие торренты «все мульты диснея» и «все фильмы оскара». пользователи, которые их хотели посмотреть — залили нам на скачку по две копии :)
Покажите мне пожалуйста сайты с сравнительными отзывами. Я видел сайты с текстовыми, видел с оценочными, где народ ставит или 0 или 10 и в результате оценки становятся полностью неинформативны…
Спасибо за ответ :) В принципе она действительно ближе, но без инвайтов туда не попадешь :(
И потом это все-таки сайт и к тому же идеи сравнительных отзывов мне лично вообще в интернете не попадались. Может я не прав, но мне кажется, что такие идеи были бы интересны именно в технологичном плане.
мне почему-то кажется, что это общая болезнь бюджетной сферы
я в свое время делал наброски дизайна в месте где учился и в какой-то момент, после жестоких споров как расположить менюшку и какие еще «небольшие» изменения в макет внести, мне было сказано что человек, который принимает дизайн — это мой оппонент и пока он не примет макет, те, кто его заказывал его просто не увидят :) на этом работы больше не продолжались :) я тогда как раз впервые увидел как такие вещи могут происходить.
по-моему все это идет от непрофессионализма, неуверенности и отсутствия понятия «ответственность».
то есть бюджетники (не буду говорить, что все, конечно, но как правило принимающие решения), к сожалению, не имеют нужного уровня знаний, но несмотря на это (и чем выше по должности, тем больше и чаще) лезут в области где не имеют необходимых навыков. неуверенность при этом маскируется как раз под разного рода дипломы, звания и регалии, причем любые притянутые, а также приглашаются соседи и знакомые, чтобы получить «консенсус» и размыть ответственность. типа если кого припрут к стенке — можно будет сказать, что вот эти и эти видели, давали советы, но их отклонили. ну или «все смотрели, вроде ничего»
к сожалению, уровень профессионализма и ответственности принимающих лиц в бюджетной сфере таков, что они сначала не могут выбрать правильного поставщика услуг, а с другой стороны не могут проконтролировать качество, поэтому и не могут морально положиться на поставщика. вообще говоря, это грустно, а тем более грустно видеть, что институт с дизайнерской кафедрой не может сделать сам сайта института.
я бы назвал это полной деградацией :)
зы для тех кто коментирует этот пост в духе «а покажи сайт», могу сказать, что не надо быть пекарем, чтобы оценить вкус пирожка. и не надо быть гениальным дизайнером, чтобы понять, что люди, которые преподают конкретный вид дизайна не знают про него ничего. или те, кто занимается приемкой дизайна некомпетентны на своем месте. как-то так.
вы все верно говорите, но я писал о той проблеме, когда владелец кода торпедирует внесение изменений руководствуясь не критерием «лучше для проекта», а критерием «а что это даст лично мне».
собственно, в статье которую я приводил, описывается именно последний случай, когда критерий «даст лично мне» подкрепляется инженерной лестницей, введенной в гугле.
в этом случае те, кто пытаются внести хорошие, годные (тм) изменения в проект жестко отсекаются от кода его владельцем потому, что ему лично это не выгодно, а не потому, что изменения плохие.
в таких случаях как раз нужно наличие внешних усилий (к примеру, от менеджеров), чтобы пробить внесение, но в случае гугла это похоже как раз и не работает, тк там организация процесса разработки этого не предусматривает. а в результате увольняются инженеры.
еще раз повторюсь, что разрешение владельца, readability approval и прочие вещи — вещь несомненно хорошая, но вводя их в большой организации стоит предусматривать варианты когда по каким-либо _личным_ причинам разработчики будут использовать созданные механизмы для достижения _личных_ целей, а не целей компании.
«как правило разбирается» еще не означает «разбирается всегда лучше». а из этого следует, что если приходит новичок (в компании, но с хорошим бекграундом вне нее), видит явный косяк в архитектуре, пытается сам его поправить, правит, а код откатывается тимлидом со словами «я разбираюсь лучше» и все попытки обсудить архитектуру спускаются им же, ссылаясь на свой заслуженный авторитет, то такая ситуация решается только на уровне менеджера проекта с привлечением сторонних специалистов и ревью кода тут ну никак помочь не сможет, к сожалению :(
насколько я понимаю в штатах есть законодательство на эту тему (которое кстати не работает у нас), а именно вопросы NDA.
но и в том и в другом случае — такие действия при всплывании наружу являются волчьим билетом при найме на другую работу в лучшем случае, и тюрьма в худшем.
а исходники… да кому они, если честно, нужны без людей, которые знают что там написано и людей, которые стояли рядом и занимались маркетингом, анализом требование и прочее и прочее :)
как мне кажется вы смешиваете несколько разных вещей:
— «валится на половине тестов» — решается периодическим прогоном этих тестов и раздачей пряников тем кто внес изменения которые их валят, это вообще сильно техническая вещь.
— безбожно тормозит, делает не то, что нужно — вопрос контроля разработчика со стороны тимлидов или тимлидов со стороны менеджмента
а вот ревью кода это ближе именно к стилю написания, но не только, наверно. собственно сам термин (readability review) врядли относится к тому, что код падает на тестах :)
частично у вас также затронут вопрос когда контроля внесений изменений вообще нет, про это я написал выше, что я нигде не говорил что такой контроль должен в принципе отсутствовать. он должен быть, но в ситуации с гуглом у него есть конкретные негативные стороны, описанные в приведенной статье.
я в свое время, кстати попадал в ситуацию, когда любое изменение кода с моей стороны встречало резко негативную реакцию сотрудника в моем проекте и любую правку в соседнем с моим коде приходилось проводить с боем и матом. в результате я оттуда уволился и никогда об этом не жалел :)
приятно конечно работать с понимающими людьми, но в случае с гуглом, а он уже стал большой компанией и давно перестал быть стартапом, подобные сайд эффекты начинают уже влиять на разработку. в стартапах же такое решается (или не решается, в отдельных случаях типа моего) как правило вменяемым средним менеджментом и как правило просто незаметно.
Вы рассматриваете ситуацию, когда контроля вообще нет, а такие крайности конечно чреваты совсем другим уровнем косяков. Вопрос не в наличии на самом деле контроля со стороны владельца, вопрос в том — насколько много надо владельцу давать прав на блокировку изменений. ну и также вопрос в том — как построить процесс ревью, чтобы исключить негативный человеческий фактор со стороны тимлидов и владельцев _в условиях инженерной лестницы гугла_.
в статье сказано про стартапы, в которых проще банально из-за того, что там разработчики как бы это сказать… более равные :)
.
В «старой» версии это очевидное казалось бы противоречие прописано черным-по-белому. А откуда вылез этот бред?
Это не говоря уже о физической невозможности выяснить месторасположение клиента. А если он со своей итальянской картой находится в Чаде, а платит через сервер компании в Гонконге, которые расположены сами по себе в штатах? Тут как бы, ну, очевидные вопросы-то… И конечно, закон никак не поддерживается (определение местоположения клиента) нашими родными плат сервисами с машинками для чеков в датацентре какого-нить южного чертанова, те если п и хотел бы внезапно платить, да техницки никак…
— графики кактуса более понятны для меня и еще пары человек на проекте. по цветам, по интерполяции данных. в целом это самое кардинальное для меня отличие тк в заббиксе я вообще ничего не понимаю. админ который нам поставил заббикс сказал что он вообще в графиках ничего не видит :) почему — стало потом понятно :)
— заббикс по дефолту (!) умеет чаще опрашивать свои щупы, но при желании можно и кактус так настроить. в целом мне ни разу не понадобилась такая более частая статистика
— у заббикса другая система организации графиков. кактус мне лично больше нравится с древовидной структурой серверов
— заббикс сильнее грузит тачки чем кактус, те в топе на нагруженных машинках я его периодически вижу. кактус — ни разу
отказали. вобщем досрочно и за такой срок у меня так больше ни с одним предметом не получалось :)
— коллега видел >1300, тоже отзывался
— когда-то один из написанных проектов примерно полчаса держал трафик от дигга в одном из разделов после попадания в топ :) сейчас другой уже держит больше, но на дигге так больше в топ не вставали
— как-то в процессе работы проекта выяснил, что есть мегабольшие торренты «все мульты диснея» и «все фильмы оскара». пользователи, которые их хотели посмотреть — залили нам на скачку по две копии :)
Покажите мне пожалуйста сайты с сравнительными отзывами. Я видел сайты с текстовыми, видел с оценочными, где народ ставит или 0 или 10 и в результате оценки становятся полностью неинформативны…
Может я что-то упустил?
Зарегистрироваться на сайте можно по приглашению одного из зарегистрированных участников сообщества.
?
И потом это все-таки сайт и к тому же идеи сравнительных отзывов мне лично вообще в интернете не попадались. Может я не прав, но мне кажется, что такие идеи были бы интересны именно в технологичном плане.
я в свое время делал наброски дизайна в месте где учился и в какой-то момент, после жестоких споров как расположить менюшку и какие еще «небольшие» изменения в макет внести, мне было сказано что человек, который принимает дизайн — это мой оппонент и пока он не примет макет, те, кто его заказывал его просто не увидят :) на этом работы больше не продолжались :) я тогда как раз впервые увидел как такие вещи могут происходить.
по-моему все это идет от непрофессионализма, неуверенности и отсутствия понятия «ответственность».
то есть бюджетники (не буду говорить, что все, конечно, но как правило принимающие решения), к сожалению, не имеют нужного уровня знаний, но несмотря на это (и чем выше по должности, тем больше и чаще) лезут в области где не имеют необходимых навыков. неуверенность при этом маскируется как раз под разного рода дипломы, звания и регалии, причем любые притянутые, а также приглашаются соседи и знакомые, чтобы получить «консенсус» и размыть ответственность. типа если кого припрут к стенке — можно будет сказать, что вот эти и эти видели, давали советы, но их отклонили. ну или «все смотрели, вроде ничего»
к сожалению, уровень профессионализма и ответственности принимающих лиц в бюджетной сфере таков, что они сначала не могут выбрать правильного поставщика услуг, а с другой стороны не могут проконтролировать качество, поэтому и не могут морально положиться на поставщика. вообще говоря, это грустно, а тем более грустно видеть, что институт с дизайнерской кафедрой не может сделать сам сайта института.
я бы назвал это полной деградацией :)
зы для тех кто коментирует этот пост в духе «а покажи сайт», могу сказать, что не надо быть пекарем, чтобы оценить вкус пирожка. и не надо быть гениальным дизайнером, чтобы понять, что люди, которые преподают конкретный вид дизайна не знают про него ничего. или те, кто занимается приемкой дизайна некомпетентны на своем месте. как-то так.
собственно, в статье которую я приводил, описывается именно последний случай, когда критерий «даст лично мне» подкрепляется инженерной лестницей, введенной в гугле.
в этом случае те, кто пытаются внести хорошие, годные (тм) изменения в проект жестко отсекаются от кода его владельцем потому, что ему лично это не выгодно, а не потому, что изменения плохие.
в таких случаях как раз нужно наличие внешних усилий (к примеру, от менеджеров), чтобы пробить внесение, но в случае гугла это похоже как раз и не работает, тк там организация процесса разработки этого не предусматривает. а в результате увольняются инженеры.
еще раз повторюсь, что разрешение владельца, readability approval и прочие вещи — вещь несомненно хорошая, но вводя их в большой организации стоит предусматривать варианты когда по каким-либо _личным_ причинам разработчики будут использовать созданные механизмы для достижения _личных_ целей, а не целей компании.
в частности, фразу «Вы рассматриваете ситуацию, когда контроля вообще нет»
«как правило разбирается» еще не означает «разбирается всегда лучше». а из этого следует, что если приходит новичок (в компании, но с хорошим бекграундом вне нее), видит явный косяк в архитектуре, пытается сам его поправить, правит, а код откатывается тимлидом со словами «я разбираюсь лучше» и все попытки обсудить архитектуру спускаются им же, ссылаясь на свой заслуженный авторитет, то такая ситуация решается только на уровне менеджера проекта с привлечением сторонних специалистов и ревью кода тут ну никак помочь не сможет, к сожалению :(
но и в том и в другом случае — такие действия при всплывании наружу являются волчьим билетом при найме на другую работу в лучшем случае, и тюрьма в худшем.
а исходники… да кому они, если честно, нужны без людей, которые знают что там написано и людей, которые стояли рядом и занимались маркетингом, анализом требование и прочее и прочее :)
— «валится на половине тестов» — решается периодическим прогоном этих тестов и раздачей пряников тем кто внес изменения которые их валят, это вообще сильно техническая вещь.
— безбожно тормозит, делает не то, что нужно — вопрос контроля разработчика со стороны тимлидов или тимлидов со стороны менеджмента
а вот ревью кода это ближе именно к стилю написания, но не только, наверно. собственно сам термин (readability review) врядли относится к тому, что код падает на тестах :)
частично у вас также затронут вопрос когда контроля внесений изменений вообще нет, про это я написал выше, что я нигде не говорил что такой контроль должен в принципе отсутствовать. он должен быть, но в ситуации с гуглом у него есть конкретные негативные стороны, описанные в приведенной статье.
я в свое время, кстати попадал в ситуацию, когда любое изменение кода с моей стороны встречало резко негативную реакцию сотрудника в моем проекте и любую правку в соседнем с моим коде приходилось проводить с боем и матом. в результате я оттуда уволился и никогда об этом не жалел :)
приятно конечно работать с понимающими людьми, но в случае с гуглом, а он уже стал большой компанией и давно перестал быть стартапом, подобные сайд эффекты начинают уже влиять на разработку. в стартапах же такое решается (или не решается, в отдельных случаях типа моего) как правило вменяемым средним менеджментом и как правило просто незаметно.
в статье сказано про стартапы, в которых проще банально из-за того, что там разработчики как бы это сказать… более равные :)