Индия, возможно, перейдет на Linux

Давно пора!

Вот оказывается чем сейчас занимаются уволенные в америке индусы-программисты.

Индия скоро будет из себя радиоактивную землю выковыривать, а не думать о светлом будущем linux.

даёшь ядерные ракеты под управлением linux!

сомневаюсь что они будут унифицироваться с китайцами -- у них издревле вооруженный до зубов нейтралитет.

Nu blin, ne havatalo nam toka indeizov ispol'zuuchie linux

Забавно звучит заголовок новости. Как будто Индия - это такая небольшая фирма, занимающаяся продажей туалетной бумаги через интернет. В этой стране между прочим народу живет больше чем в США и России вместе взятых. А сколько там компьютеров остается только догадываться.

Скать что у Индии с Китаем вооруженный нейтралитет, это значит ОЧЕНЬ приукрасить обстановку. Китай в свое время оккупировал часть индийской терретории и индусы этого совсем не забыли, да и когда Далай Лама свалил от китайских коммунистов он отвалил в Индию чем очень насолил китайцам, мало того на той почве что у Индии с Пакистаном очень плохие отношения Китай просто с удовольствем последнему оружие продает. Это я к тому что если кто-то говорит в Индии мол давайте делать как китайцы, то ему за это просто по мозгам надают.

может хватит кричать о каждой n-ой установке линукса?

>может хватит кричать о каждой n-ой установке линукса?
если вся Индия, это всего лишь n-ая установка линукса, то, пожалуй, хватит. :)

> Вот оказывается чем сейчас занимаются уволенные в америке индусы-программисты..

То что уволенные - врятли. Местные дибилы в штатах только что и могут как жрать гамбургеры перед теликом. Мозги у них там - импортные ;)
C другой стороны - нахер нужна эта америка - вся Индия туда не переедет, так что приняли правильное решение - дать работу мозгам у себя на родине. Да и за лицензии M$ не надо будет деньги отстегивать штатам - пущай сами покупают свой майкрософт раз он такой хороший ;) Надо бы и в России так делать - свои кадры растить и пестовать, а не жопу подставлять корпорациям типа майкрософта.

2anonymous (*) (2002-05-30 22:00:51.018): "То что уволенные - врятли."
Сразу чуствется что с индусами не работал. Их дальше БД допускать нельзя и то при условии, что база уже сделана, т.к. сдизайнирвоаны таблицы и ключи выбраны правильно.
"Местные дибилы в штатах только что и могут как жрать гамбургеры перед теликом. Мозги у них там - импортные ;)"
Свежо предание, в IT работает куча американцев, очень часто они руководят группами и писать функции это и обезьяне можно поручить.

В одном учебнике по логике прочел такую байку:

Приезжает в Новую Англию, типа в Бостон, какой-то именитый протестанский епископ. Ну его, ясен пень, встречает толпа журналистов. Хотят какую-нибудь сенсацию надыбать, как-нить подколоть пастора. Пастор сходит с парахода, и ему сразу же задают следующий вопрос: "Что вы думаете о борделях в нашем городе ??" Пастор осторожно так спрашивает: "А что, у вас в городе есть бордели ???" На следующий день все газеты выходят с заголовком: "Первый вопрос приехавшего к нам епископа Хххх - "Есть ли в вашем городе бордели ??" ".

Я это к чему... Мне эту истроию эта новость напомнила :-)))))))))

Наша деревня Ебанатовка тоже возможно скоро перейдет на линукс...

анонимусу, который индусов дальше БД пускать не хочет:

Мальчик, посмотри версии последних IOS. 9 из десяти индусами собраны.

2fearan: "Мальчик, посмотри версии последних IOS. 9 из десяти индусами собраны"
Я твою фразу не понял. То ли 9 из 10 программистов индусы, толи 9 из 10 билдов собирались индусами, если последнее, то смею тебя заверить что сборка большого проекта идет через скрипты и на этой работе обычно сидит человек, который программировать на уровне нормального программиста практически не умеет.

Гребанная КЛента ссылается на Newsforge.
Кто-нибудь смог найти и прочитать первоисточник???

Виндузятник

2 anonymous (*) (2002-05-31 10:09:00.476): Еще один чайник пришел. На билдах как раз сидят свирепые монстры, которые в случае чего билд брейк могут сами пофиксить и разобраться почему не билдится и кто виноват. Кроме того, у них как правило они еще пишут как правило несколько нехилых кусков приложения и делают кастом функции в инсталлере. У нас работает такой паренек - он один из самых сильных программеров в группе.

2anonymous (*) (2002-06-01 04:31:46.226): "Еще один чайник пришел"
Это ты про себя?
"На билдах как раз сидят свирепые монстры, которые в случае чего билд брейк могут сами пофиксить и разобраться почему не билдится и кто виноват"
И что интересно, к программированию системы это НЕ ИМЕЕТ НИ КАКОГО ОТНОШЕНИЯ. Т.к. если чего не билдится, то алгоритм прост: 1) В каком файле ошибка 2) смотрим кто последний коммитил. Все более ни чего делать не надо.
А вот что они делают пожалуйста не надо рассказывать. Я это могу наблюдать что в своей конторе, что еще в парочке.
"У нас работает такой паренек - он один из самых сильных программеров в группе."
Бред. Потому как если он сильный то тратить его время на работу по билдам не позволительная роскошь.

А в чувашии, собаки угрохали миллионы долларов на установку M$ продуктов :( вот этого я никак не понимаю. скорее всего те которые это сделали, или отмывают бабки, или не переваривают опенсорс в любом виде Статья лежит тут: http://www.cnews.ru/news/comp/2002/05/28/20020528173621.shtml

Одно слово МУДАЧЬЕ!

2 anonymous (*) (2002-06-01 06:28:24.151): Ага, лучше было посадить идиота, чтобы nightly builds по неделям никто не мог нормально тестировать. Чайники, блин.

2anonymous (*) (2002-06-02 04:40:29.547): Поработай и узнаешь, что на билдах сидят те кто не смог стать программистом, но уже достаточно грамотен чтоб идти в QA. Если мне кто-то заявляет что у них билд-персон один из самых сильных в группе, то этот человек либо состоит в группе билдеров либо ни когда не работал в группе.

Просто билды и инсталляция/деплоймент у этого чела - это одна из областей, которыми он занимается. У QA свой билд процесс, и он, в отличие от основного процесса не еженощный, а вообще непрерывный, и билдятся там не только бинарники приложения, но и тулзы для его тестирования и automated test cases. Когда кто-нибудь чекинит говно, этот билд ломается, и тот кто зачекинил говно убирает за собой. В 5 часов вечера закрывается checkin window, и тот кто отвечает за билд запускает билд. Билдится все это дело (на сегодняшний день) примерно 2.5 часа (на четырехпроцовом xeon). Если все хорошо (а обычно все хорошо) на выходе получаются инсталеры для дебаг билда, шип билда и локализованных билдов. Если не все хорошо, чел лезет в исходники и либо сам правит то, что не отловил QA rolling build (а потом его изменения review'ит ответственный девелопер), либо (редко) заставляет править ответственного девелопера, если чувствует что не до конца понимает area'ю. Таким образом, лишь где-то 40 минут - час в день у него уходит на билды, а если все хорошо, то и вообще ничего не уходит. Человеку на таком месте девелоперы должны доверять (а если ты сам девелопер, то знаешь, что девелоперы - люди патологически недоверчивые, когда речь идет о их коде). Человек должен быть способен справиться в случае чего с ЛЮБЫМ (ну за исключением уж совсем фатальных) screw-up'ом, потому что из 5 дней в неделе, 3 дня QA нужны готовые свежие билды, а девелоперы могут и болеть, и в отпуск уходить.

Последнему анониму: а что, у вас девелоперы не пытаются собрать свой модуль до занесения в него изменений (если бы пытались, кажется что вероятность поломки дерева (прихода его в несобираемое состояние) не очень велика). А QA у вас начинает работать только для тех модулей, которые считаются функционально законченными или просто, берут и без спроса тестируют (маразм имхо)? А какую систему контроля версий используете - cvs? Спасибо за ответы..

1. Собирают, конечно. Но если поддерево куда чекинишь очень большое, либо имеет много dependencies, то полностью его пересобирать никто не будет из-за каждого чекина (сам модуль пересобирается, если изменения нетривиальные), а потому зачекиненое другим девелопером изменение может дать билд брейк на твоем модуле. Такое бывает редко, но бывает.

2. QA тест кейсы пишутся для тех модулей, которые официально delivered. Пересобирается всё после каждого чекина (ну не каждого, а следующего после того как билд закончился), чтобы отловить брейки в тесткейсах по возможности _до_ официального nightly build.

3. Я ж говорил, контора у нас очень большая, а потому система контроля версий у нас своя собственная. Очень хорошая система контроля версий. CVS с ней и рядом не валялась.

2anonymous (*) (2002-06-02 11:39:44.291): "3 дня QA нужны готовые свежие билды, а девелоперы могут и болеть, и в отпуск уходить."
Мда... Т.е. у вас QA тестирует новый билд в среднем каждый второй день... И что они успевают за 48 часов оттестировать? Это я к тому что большенство longetivity тестов просто не успеют даже дойти до половины за это время...

Баги регрессят, новые ищут. А у вас не так? Не каждая бага, которую девелопер считает пофиксеной на самом деле пофиксена. И когда девелопер чекинит новую функциональность, баги в ней есть for sure. На всякий случай скажу, что пишем мы систему с веб- и аутлук клиентом рассчитаную на 300-500 юзеров. Шипимся в сентябре.

Кстати, это только platform и application тестеры получают новый билд раз в 2 дня. Перформанс, стресс и то что мы называем invalid parameter тестинг идут на отдельных кластерах и не чаще чем раз в неделю (чаще они просто не успевают).

"Баги регрессят, новые ищут. А у вас не так?"
Все так, вот только QA это делает на каком-то одном билде, скажем 123, и все баг репорты пишутся относительно этого билда, потом у ним приходит билд 126 (124 и 125 просто тестовые билды, чтоб внутри группы глянуть пофиксены ли самые страшные баги, чем в прочем билд-персон и занимается, но окончательное слово за QA). И вот по всем багам их проглого билда делается тест и если что-то поменялось скажем в usb стеке, то тестируются все usb устрйоства что есть у нас. На самом деле QA цикл составляет у нас 2 недели и в промежутке этих двух недель билд-персон просто работает с QA и проверяет чтоб уж откровенную лажу не гнали и выкидывает из их шагов по воспроизведению лишнии шагии при этом пытается понять откуда у ошибки ноги растут, чтоб программист не терял драгоценное время на ответы на простые вопросы.

Если у нас билды будут раз в 2 недели - мы не зашипимся НИКОГДА. Когда близятся дедлайны QA ставят себе private builds каждый день вообще, чтобы turnaround time на "страшных" ошибках сократить до 24 часов max, а иногда даже тестируют хотфиксы (девелопер на шару выкладывает dll там или aspx или sql, xsl, *.cs)

2anonymous (*) (2002-06-05 09:46:32.89): "Если у нас билды будут раз в 2 недели - мы не зашипимся НИКОГДА"
Посмотри на это с другой стороны - QA вместо того чтоб сделать полное тестирование постоянно пытается делает это на каком-то промежуточном образце, естетсвенно они не успевают нормально оттестировать. Ведь за две недели набирается достаточно багов чтоб загрузить работой всех программистов на 200%. А игра в догонялки к добру не приводит.
"чтобы turnaround time на "страшных" ошибках сократить до 24 часов max"
Критические ошибки это отдельный разговор. Из естетвенно убирают как можно быстрее и при этом лучше задержат очередной билд чем дадут ему пойти на очередной круг тестирования. Да кстати ты представь себе на секунду, что твой продукт будет выходить не только под маркой компании где ты работаешь, но и другой компании которая на него ставит свой лэйбл и их QA тоже сабмитит нам баги, прикинь присылать им каждый второй день билд (я это про компанию где я работаю, очень весело в такой ситуации работать)...

У нас таких партнеров (сабмитящих баги - ШЕСТЬ). А полное тестирование на каждом билде не делается. Только automated и ad-hoc. Или кто-то из QA целенаправленно ковыряется в своих областях и пишет тест-кейсы.

Т.о. пришли к тому что билды делать каждые два дня не надо (раз их не тестируют по нормальному). Но вернемся к нашим баранам - у билд инженера достаточно работы, чтоб еще и программировать, и как результат он не может быть одним из крутых в группе, что возвращает нас к моему постингу anonymous (*) (2002-05-30 11:31:17.567)