Ответ на сообщение Re: Программист. пользователя zumzum
35 мс на "select SYSDATE from DUAL" это че та дофига! 400-600 мс на подключение к базе это вообще за гранью, ну и в принципе есть такое понятние как connection pool, если чо
|
|
|
 |
|
- ← предыдущая
- 1 ..
- 9
- 10
- 11
- 12
- 13
- 14
- следующая →
Ответ на сообщение Программист. пользователя Камон
инфраструктурные потери в сотни (или даже тысячи?!!) милисекунд это ППЦ. Что-то там не так
Любой веб-сайт с любой базой данных.
Ответ на сообщение Re: Программист. пользователя zumzum
Не важно откуда появились "плохие данные", важно их побыстрее и внятнее продемонстрировать.Ответ на сообщение Re: Программист. пользователя Камон
35 мс на "select SYSDATE from DUAL" это че та дофига! 400-600 мс на подключение к базе это вообще за гранью, ну и в принципе есть такое понятние как connection pool, если чо
Про пул я там же и написал, а что, пхп уже научился с ним работать?
По поводу всего остального - запустите профайлер да посмотрите, сколько чего там занимает. "Подключение к базе" - достаточно сложная штука, там всякие нехорошие "контексты" и "сессии" создаются, да еще и "инициализации" дурацкие норовят запуститься.
Ответ на сообщение Re: Программист. пользователя Камон
Не важно откуда появились "плохие данные", важно их побыстрее и внятнее продемонстрировать.
Да ладно? В БД какой-то чудак отключил FK и порушил ссылочную целостность, запрос возвращает пустое множество вместо родительской записи. Всё, приехали, срём в лог, генерируем код ошибки, показываем пользователю страницу "произошел системный сбой, звонить в поддержку".
Пользователь написал слово "х.й" вместо даты рождения - тут же ему подчеркиваем элемент ввода и говорим, что "ввести нужно дату в формате дд-мм-гггг".
Кто-то дергает сервис за метод, вообще говоря не предназначенный для публичного использования? Убираем метод из публичного API и ждем пока прибегут ругацца.
Но уж точно не пишем тонны кода, обрабатывающие все возможные ситуации, в каждом методе.Ответ на сообщение Re: Программист. пользователя zumzum
К примеру:
выполнение скрипта вычисляющего агрегатные функции на нескольких таблицах, запросом обрабатывалось примерно по сотне записей в бд. Ответ на десктопный клиент приходил за 20 мс, т.е. включался еще 1 уровень, передача данных на клиента, сериализация - десериализация. Непонимаю откуда 35 ms на select from dual взялсяОтвет на сообщение Re: Программист. пользователя zumzum
про БД - ок, согласен, чем это правда отличается от того про что я говорил непонятно.
Про день рождения - не в тему, валидация UI полей и валидация входных параметров метода вещи из разной оперы.
> Кто-то дергает сервис за метод, вообще говоря не предназначенный для публичного использования?
это вообще не про проверку входных параметровИсправлено пользователем Камон (06.03.12 08:26)
Ответ на сообщение Re: Программист. пользователя zumzum
> Про пул я там же и написал, а что, пхп уже научился с ним работать?
Не знаю, но если пхп не работает с пулом, то это вообще ппц.
тут вот
http://stackoverflow.com/questions/39753/connection-pooling-in-php
пишут что пул можно организовать через mysql_pconnect function.Ответ на сообщение Re: Программист. пользователя Камон
запросом обрабатывалось примерно по сотне записей в бд.
Т.е. минимальные отличия от SELECT FROM DUAL - все 20мс можно смело записывать в инфраструктурные потери.
включался еще 1 уровень, передача данных на клиента, сериализация - десериализация.
Угу, те самые "инфраструктурные потери". Набросайте простейший скриптик - сохраните значение microtime() в переменную, сделайте вызов того же "select from dual", вычтите из нового значения microtime() сохраненное. В результате получите потери на инфраструктуру. Можете еще db_connect туда же впихнуть интереса для.
Непонимаю откуда 35 ms на select from dual взялся
Из TOAD, только что. Понятно, что все зависит от нагрузки на сервер, производительности того самого сервера, конфигурации и загрузки сетевого интерфейса и т.д.-
Ответ на сообщение Программист. пользователя Камон
про БД - ок, согласен, чем это правда отличается от того про что я говорил непонятно.
просто разные по природе "входные параметры" получаются, с разным механизмом реакции на них.
Про день рождения - не в тему, валидация UI полей и валидация входных параметров метода вещи из разной оперы.
Почему? В валидаторе баг, слово "х.й" уехало в сервис, язык с нестрогой типизацией (например, пхп).
это вообще не про проверку входных параметров
Почему? Чувак со второго этажа работает над похожей задачей, в процессе реализации натыкается на наш (случайно оказавшийся в паблике) метод, который делает "то, что надо", совершенно резонно решает его переиспользовать, делает ошибку, наш метод выбрасывает исключение.Ответ на сообщение Re: Программист. пользователя Камон
Пишут что пул можно организовать через mysql_pconnect function.
Как раз пишут что нельзя, а mysql_pconnect и пул - две разные вещи.
There is no connection pooling in php.
mysql_pconnect and connection pooling are two different things. There are many problems connected with mysql_pconnect and first you should read the manual and carefully use it, but this is not connection pooling.
Ну и так, положа грязную руку на потные яйца - сколько пхп-программистов вообще знают, что такое "connection pool"? А сколько из них дергают mysql_connect перед КАЖДЫМ запросом?Ответ на сообщение Re: Программист. пользователя zumzum
> просто разные по природе "входные параметры" получаются, с разным механизмом реакции на них.
Ну да, но ведь ты же написал: ошибку в лог, клиенту 502 - нормальная обработка, все правильно.
> Почему? В валидаторе баг, слово "х.й" уехало в сервис, язык с нестрогой типизацией (например, пхп).
Ну да, но ведь ты же написал:
"тут же ему подчеркиваем элемент ввода и говорим, что "ввести нужно дату в формате дд-мм-гггг""
т.е. обработка входных данных есть, а уж как реагировать зависит от логики приложения, надо так - значит надо так.
> натыкается на наш (случайно оказавшийся в паблике) метод
Ну это бага из другой темы, если ты не заметил что метод паблик и думаешь что им кроме внутренностей никто не пользуется то что тут можно поделать, в этом случае надо просто фиксать уровень доступа.Исправлено пользователем Камон (06.03.12 08:59)
Ответ на сообщение Re: Программист. пользователя zumzum
ну хотя бы некая эмуляция пула. Коннектиться к базе каждый раз это жестоко. Без понятия насчет среднего уровня пхп программистов, но что такое конекшн пул программист знать должен, а вот кто такой Касьянов нет
Ответ на сообщение Программист. пользователя Камон
- ошибку в лог, клиенту 502
О чем я и написал изначально - три принципиально разных подхода к решению проблемы "некорректных внешних данных" в зависимости от их, данных, природы.
- обработка входных данных
- фиксать уровень доступа.
Ответ на сообщение Re: Программист. пользователя zumzum
Пока утро...
1. Нету у ПХП (5.1) connection пула... по крайней мере я не нашел хде. Соединение (и много чего другого) создается каждый раз на каждый запрос... это действительно трабл... ну, скажем так, по мере изучения ПХП в связке с Мускулем постепенно узнаю, что "много чего нет", начиная с синтасксических диаграмм языка...
2. Потери на организацию старта обработки запроса, в т.ч. и по факту БД - конечно же не 30-50мс... поболе будут. Но! В этом, как раз и кроется острая необходимость оптимизации исходного кода! Упрощенно:
В стартовый код входит процесс аутентификации юзверя... было: 150кб (или около) только создаваемых структур и данных (рекорд - подкласс, дублированный 8 раз) и по профайлеру около 75мс только обработки и создания этого колхоза данных... зато ООП. Убрали... стало 5мс и 1.5кб данных.
Ещё раз, типовое рассуждение "нафига тут экономить... а! это свойство есть у этого класса... " приводит именно к такой структуре результата. Как пример стартовая инициализация Zend Framework по профайлеру отжирает около 10-15 МЕГАБАЙТ. Плюс время.
Это и есть причина потерь на соединение с БД... это и есть способ деградации отрасли... Копрокодерство уже настолько стало обычным делом, что его вонь уже никем по-просту незаметна...а кому-то даже приятна...
Скока, скока ресурсов требует Жаба-машинка тока для себя любимой? Скока-скока оперативки требует седьмая винда? А почто, практически то же самое у мене под OS/2 ходило в 4 мегах, а в 12 так даже летало?
На соединение с базой Mumps скока ресурсов треба? А времени уходит?
Ну и так, положа грязную руку на потные яйца - сколько пхп-программистов вообще знают, что такое "connection pool"? А сколько из них дергают mysql_connect перед КАЖДЫМ запросом?
Так вот про ЭТО НЕЗНАНИЕ и нежелание узнать, я и пишу всю тему!!!"Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин
(а не на "вертикаль власти" надеяться)Ответ на сообщение Re: Программист. пользователя tolstopuz
Да, были времена ... Когда Zend Framework на 12 мегабайтах под OS/2 летал
Ноныча оно не то что давеча ...Ответ на сообщение Re: Программист. пользователя boroduj
Моё мнение по статье - любую идею всегда можно довести до абсурда. Как хорошую, так и плохую. Любую. Даже эту.
или по-другому: "всё хорошо в меру". На практике (уже могу сравнивать): код писанный "как попало" главное запуск продакшн - "бабки наше фсё" приводит к тому, что из задуманного реализуется 2%... остальные силы уходят на патчинг багов вместо развития. Разумная (!) оптимизация кода и постоянный полезный (по мере развития) рефакторинг снижает потери времени на тестирование, сопровождение и высвобождает ресурсы на развитие. За последние 2 месяца по нашей команде сделано больше нового кода, чем таким же составом (даже чуть больше) 2 года назад примерно в 2 раза. При этом, попутно(!), улучшено качество того кода, который писался ранее. Это мнение руководства, ежели вчё. А оно, как понятно сильно влияет на з/п...
Проблема для таких "перфекционистов" в том, что не надо увлекаться в ущерб результату (правило 80/20 и здесь полезно), но и нельзя поддаваться давлению начальства "сделай залипуху, потом поправим"... не бывает этого "потом"! Потом - будет просто стыдно. И никакой опыт не покрывает вонь копрокодирования."Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин
(а не на "вертикаль власти" надеяться)Ответ на сообщение Re: Программист. пользователя Камон
Глупая шутка. Особенно, если внятно НЕ сможете объяснить чего такого ядро семерки делает, чего не делала Os/2... то бишь на что потрачены мегабайты и гигагерцы..."Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин
(а не на "вертикаль власти" надеяться)
Ответ на сообщение Re: Программист. пользователя tolstopuz
Напомню: оптимизирован в примере был код в части УСТРАНЕНИЯ повторных блорков исполнения, ЛИШНИХ ветвлений...
это не оптимизация, это улучшение читабельности, как раз оптимизированный код может быть ну очень не читаем, как раз иногда если компилятор/интерпретатор слишком умный повторный, большой по времени исполнения, блок может быть отправлен на исполнения в другую треду из пула на другой процессор. Но такой код совсем плохо читаем, правда.
а то, что все стало медленней работать, ну дык сколько рюшечек добавленно, читабельный код не всегда самый быстрый, ну и быстрое железо индульгенция на не запуск профайлера и отсутствие временных затрат на этот шаг, не_даром слово успех созвучно со словом успел. Видел много попыток сделать правильно и красиво, почти все проиграли, тем кто делал "на коленке", зато быстро, зато потом можно было причесать и навести порядок.Схватил жопку в брюсселе
бабами любимы
тёплые коты
а чего добился
в этой жизни тыОтвет на сообщение Re: Программист. пользователя Камон
ну хотя бы некая эмуляция пула. Коннектиться к базе каждый раз это жестоко.
Когда я последний раз всерьез видел пхп, там самой крутью было "одно соединение с базой на каждый хттп-запрос". От того и весело мне, что на пхп народ за миллисекунды бьется.Ответ на сообщение Re: Программист. пользователя tolstopuz
В стартовый код входит процесс аутентификации юзверя... было: 150кб (или около) только создаваемых структур и данных (рекорд - подкласс, дублированный 8 раз) и по профайлеру около 75мс только обработки и создания этого колхоза данных... зато ООП. Убрали... стало 5мс и 1.5кб данных.
Ну это надо смотреть, откуда ноги растут у этого колхоза. А то бывает, что заказчик (или программист, зависит) хочет всего и сразу, и наворачивает такую развесистую клюкву на аутентификацию/авторизацию, что аж диву даешься. И роли тут, и категории, и группы, и раздельный доступ до каждой кнопки... Потом из этого зоопарка максимум 10-15% используется.
Скока, скока ресурсов требует Жаба-машинка тока для себя любимой?
На сегодняшний день, когда в среднестатистическом десктопе стоит два гигабайта памяти - копейки. Зато сразу - кроссплатформенность, отсутствие "тупых" проблем с утечками памяти и кривыми указателями (в плюсах сплошь и рядом - "вчера работало, сегодня упало, завтра опять работает", ах ты ж, память освободили а указатель не занулили), устойчивость к атакам на переполнение буфера. Ну и скорость разработки в разы выше, конечно.
На соединение с базой Mumps скока ресурсов треба? А времени уходит? :)
А сколько ресурсов треба, чтобы в иерархической БД написать простенький запрос табличек на десять, с сортировками, группировками и агрегатными функциями? Ну так, отчетик пользователи просят.
Так вот про ЭТО НЕЗНАНИЕ и нежелание узнать, я и пишу всю тему!!!
Дык работает же? И программисты стоят по десять баксов за пучок. А то пойдёшь, бывалоча, к ЗНАЮЩИМ, получишь от них счёт миллиона на полтора-два, и ищешь где бы верёвку украсть и мыло подешевле купить.
Всё нормально, законы рынка: "как заплачено - так и за%%%ячено".Ответ на сообщение Re: Программист. пользователя tolstopuz
Проблема для таких "перфекционистов" в том, что не надо увлекаться в ущерб результату (правило 80/20 и здесь полезно), но и нельзя поддаваться давлению начальства "сделай залипуху, потом поправим"... не бывает этого "потом"! Потом - будет просто стыдно. И никакой опыт не покрывает вонь копрокодирования.
Шел 2012 год... В России начали осознавать понятие "технологический долг".Ответ на сообщение Re: Программист. пользователя tolstopuz
ядро семерки
ntoskrnl exe?5379 K?23/06/11?16:29?
Глупый наброс, чо уж.
Ответ на сообщение Re: Программист. пользователя zumzum
Но уж точно не пишем тонны кода, обрабатывающие все возможные ситуации, в каждом методе.
Да!
Приятно встретить знающего человека
42
Ответ на сообщение Re: Программист. пользователя zumzum
NoSQL - это такой модненький fud: "раз на этом работает ФЕЙСБУК, то и нам подойдет". А потом с квадратными глазами и паром из ушей рисуем простейший "поквартальный отчет о продажах, сгруппированный по поставщикам", который на SQL реализуется в три строчки.
Модненький и новенький он у тех, кто не имеет своего мнения.
Эти базы всегда были, есть и будут. Ровно как и RDBMS никуда не пропадут. 10-100 табличек можно сделать на чём угодно. Мозг приходит, когда дело к 500-1000 подбирается. Опять же не говорю, что на таком объёме нужно выбирать обязательно NoSQL. Всё задачей диктуется.
И, кстати, Вам ли не знать, что Oracle-таки выпустил свой крючок на эту тему42
Ответ на сообщение Re: Программист. пользователя zumzum
Вопрос неверный, потому что там нет табличек как таковых. Ближе понятие глобала. И те, кто пытается подлазить с шорами реляционных баз, терпят фиаско и плюются.На соединение с базой Mumps скока ресурсов треба? А времени уходит? :)
А сколько ресурсов треба, чтобы в иерархической БД написать простенький запрос табличек на десять, с сортировками, группировками и агрегатными функциями? Ну так, отчетик пользователи просят.42
Ответ на сообщение Re: Программист. пользователя tolstopuz
Глупая шутка. Особенно, если внятно НЕ сможете объяснить чего такого ядро семерки делает, чего не делала Os/2... то бишь на что потрачены мегабайты и гигагерцы...
ядро 7-ки оч. шустрое, само ядро, но вот графические финтифлюшки в user mode написаны бездарно, криво, присунуты сбоку, причем начиная с ХП. Кроме того модель/парадигма винды позволяет в ядро запихивать целые приложения, что всяко не способствует производительности. Схватил жопку в брюсселе
бабами любимы
тёплые коты
а чего добился
в этой жизни тыОтвет на сообщение Re: Программист. пользователя олдж
Модненький и новенький он у тех, кто не имеет своего мнения.
Скорее у тех, кто ниасилил правильно готовить RDBMS и пихают этот носкл во все дыры.
Эти базы всегда были, есть и будут. Ровно как и RDBMS никуда не пропадут.
Согласен. Вот, скажем, пишу я в свободное от работы и семейных дел игрушку браузерную. Баловство, конечно, но вопросы интересные возникают. Например, надо поддерживать общепользовательский чятег с историей сообщений на пицот и возможностью писать в личку/в оффлайн, всякие "битвы" (пока там только тупо кнопка "уё...ать" без особых изысков), небольшую карту с запоминанием кто в какой комнате сидит и список "пользователей в сети", чтобы народ с друзяшками мог поиграть. Не в RDBMS же эту тонну ежесекундно обновляющихся данных сваливать, правда? Сижу вот, монгу ковыряю.
Всё задачей диктуется.
С другой стороны - на работе считаем налоги, разнообразных отчетов - более 9000, плюс пользователи умеют и очень любят Crystal Reports. Куда нам тут nosql?!Ответ на сообщение Re: Программист. пользователя олдж
Я, перед тем, как выложить свой отрывочек, прогнал его и увидел прирост производительности.
речь была, что оптимизация и читабельность не часто коррелируют, сам так же предпочитаю писать, пусть оптимизят процы, делают компиляторы с интерпретаторами более умными, но я голову ломать не хочу читая код, пусть мой код будет читабельным. Нужно же было мне на какой-то пример сослаться, а тут вы.
Приведите свой пример с учётом Ваших знаний очередей команд в процессоре, потрохов php и компилирующих интерпретаторов.
зы. отдельная, вне всей системы, прогонка в профайлере сейчас стала не всегда осмысленной, слишком все сайчас слишком умное, да и учесть все входные условия сложно, например сложно при разработке учесть что дизайнер вместо того чтобы просто выключить анимацию, установит такие параметры задержек, что ее не будет видно, но ресурсы на нее все равно будут тратиться, причем именно ради оптимизации.
Схватил жопку в брюсселе
бабами любимы
тёплые коты
а чего добился
в этой жизни тыИсправлено пользователем andrew13 (06.03.12 11:24)
Ответ на сообщение Re: Программист. пользователя олдж
Вопрос неверный, потому что там нет табличек как таковых. Ближе понятие глобала. И те, кто пытается подлазить с шорами реляционных баз, терпят фиаско и плюются.
Вопрос верный, потому что решаемая в два пинка стандартная задача начинает требовать несоразмерных усилий и затрат только потому что главный архитектор решил что nosql это круто, модно и современно.Ответ на сообщение Re: Программист. пользователя zumzum
ННП (читая ветку с самого начала)
ТП пытался замутить аналог milo.com, да слегка ниасилил, я правильно всё понимаю?Ответ на сообщение Re: Программист. пользователя zumzum
ННП (читая ветку с самого начала) #2
Все так увлеклись обсуждением алгоритма ресайза картинки, что как-то даже и позабыли, что в похапе самый стандартный, отлаженный, быстрый и проверенный временем способ получить из того говна, которое загрузил пользователь, изображение c желаемым размером/соотношением сторон - это Imagick::resizeImage.Ответ на сообщение Re: Программист. пользователя zumzum
Вопрос верный, потому что решаемая в два пинка стандартная задача начинает требовать несоразмерных усилий и затрат только потому что главный архитектор решил что nosql это круто, модно и современно.
Согласен
Когда начинаешь выбирать среди этих NoSQL, то становится понятно, что не всё так радужно и годятся они только для продвинутых форумов - соц.сетей.
Монго уж точно. Гляньте CouchDB. Там есть view для отчётов42
Ответ на сообщение Re: Программист. пользователя zumzum
Посмотрел. Не совсем, больше даже совсем не... и в конце-концов... начиналось оно без меня совсем...
То, что у нас есть - не есть типовой интернет магазин. То что из этого делается - пока умолчу, можна?
Вот взял бы архитектор за основу NoSQL (хоть тот же Mumps) - было бы намного легше жить... а так приходится из реляционных таблиц городить запросы на 5-15 таблиц, да по нескольку, да потом ещё и в иерархический формат в циклах переколбашивать... благо таблички ещё не самые большие... так записей на 300 тысяч...
Фсё. перекур..."Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин
(а не на "вертикаль власти" надеяться)Исправлено пользователем tolstopuz (06.03.12 12:48)
Ответ на сообщение Re: Программист. пользователя олдж
не всё так радужно и годятся они только для продвинутых форумов - соц.сетей.
Эта точка зрения совпадает с моей на 100%. NoSQL, разумеется, имеет свою нишу, но для большинства "стандартных" проектов он не годится, во всяком случае - пока.Ответ на сообщение Re: Программист. пользователя zumzum
У этой (и люболй другой аналогично, в том числе и известных продакшн типа виндовс) ноги растут из того же самого места ...
...это "копрокодер" - типа прогер, которому на результат своего труда начхать лишь бы платили, а не то что подумалось.
Дык работает же? И программисты стоят по десять баксов за пучок.
"Это" == работает?!? и где Вы программистов по 10 баксов за пучок берете? О том и тема, что им реальная цена именно такова и есть..."Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин
(а не на "вертикаль власти" надеяться)Ответ на сообщение Re: Программист. пользователя zumzum
Для большинства "стандартных" проектов есть стандартный SQL."Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин
(а не на "вертикаль власти" надеяться)Ответ на сообщение Re: Программист. пользователя andrew13
ядро 7-ки оч. шустрое, само ядро, но вот графические финтифлюшки в user mode написаны бездарно, криво, присунуты сбоку, причем начиная с ХП.
постойте, постойте... эт-та! А как же "прогресс"? Может все-таки нормальная такая "копродеградация"?"Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин
(а не на "вертикаль власти" надеяться)Ответ на сообщение Программист. пользователя tolstopuz
Посмотрел. Не совсем, больше даже совсем не... и в конце-концов... начиналось оно без меня совсем...
Milo - это, скорее, поисковый движок, а не магазин. "Сижу на площади ленина, ищу где бы поблизости купить (в обычном магазине, не онлайновом) славянский шкаф". Т.е. та самая загрузка прайсов со всех продавцов, парсинг и каталогизация. А в потрохах у него - Lucene, Hadoop и Map/Reduce. Тут можно с блогом разработчика ознакомиться, интересное чтиво. Ответ на сообщение Re: Программист. пользователя tolstopuz
Для большинства "стандартных" проектов есть стандартный SQL.
Так в том-то и беда, что этот nosql суют куда попало - просто потому что это нынче модненько.Ответ на сообщение Re: Программист. пользователя tolstopuz
У этой (и люболй другой аналогично, в том числе и известных продакшн типа виндовс) ноги растут из того же самого места ...
По-разному бывает.
"Это" == работает?!? и где Вы программистов по 10 баксов за пучок берете? О том и тема, что им реальная цена именно такова и есть...
Конечно работает. Сайты вон строятся, дела идут, конторы пишуть. А "реальная цена" - понятие очень расплывчатое. Я вот считаю, что в Новосибирске двухкомнатной квартире в панельном доме "реальная цена" не более 15000 долларов - с учетом качества постройки, звукоизоляции (точнее - ее отсутствия), экологической ситуации и отвратительного климата. Ну да кто ж меня послушает?Ответ на сообщение Re: Программист. пользователя zumzum
Смотрел достаточно бегло, почитаю... ежели "поисковый движок", то кое что может оказаться и интересным для наших задач... что до указанных технологий пока задачи прозаичнее и то что есть - справляется успешно."Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин
(а не на "вертикаль власти" надеяться)Ответ на сообщение Re: Программист. пользователя tolstopuz
говорюже ядро нормальное, но вот на user interface-е они оторвалисьСхватил жопку в брюсселе
бабами любимы
тёплые коты
а чего добился
в этой жизни тыОтвет на сообщение Re: Программист. пользователя andrew13
говорюже ядро нормальное, но вот на user interface-е они оторвались
Хмм...
А как Вы тестировали ядро без UI ?42
Ответ на сообщение Re: Программист. пользователя tolstopuz
Глупая шутка. Особенно, если внятно НЕ сможете объяснить чего такого ядро семерки делает, чего не делала Os/2... то бишь на что потрачены мегабайты и гигагерцы...
Само собой на проверки входных параметров *продолжает глупо шутить*Ответ на сообщение Re: Программист. пользователя elfking
Открою вам тайну - 99% процентов людей хотят, искренне хотят, делать свою работу хорошо и гордиться своей ей.
Вот с этим я бы совсем согласился, если "99%" заменить на "90%". А лучше даже на "80%".
В Новосибирске много хороших программистов но очень мало хороших менеджеров и тимлидов.
Интересный вопрос. А чем сферический новосибирский тимлид или менеджер отличается от западного?
Мне казалось, что это должен быть просто продвинутый разработчик с коммуникативными навыками, с большей (моральной) ответственностью за общее дело, ну и способный организовать процесс той самой разработки с участием разноквалифицированных ребят.
Если в Новосибирске присутствуют организации с поставленным процессом (а такие, вроде бы, есть - взять хотя бы Большие Компании или нескольких относительно крупных аутсорсеров), то под влиянием этого процесса неизбежно часть разработчиков со временем будет превращаться в тимлидов и менеджеров.
То есть на смену уехавшим будет приходить новое поколение, разве нет?
Кстати, а Вы на какую позицию уехали (почему-то мне кажется, что на менеджерские позиции поначалу попасть трудно)?
Сейчас в основном уезжают на запад не за деньгам, а за нормальной жизнью. Мерить все в деньгах смысла нет - думаю каждый с какого-то возраста\планки зарплаты это понимает. В РФ сколько бы ты не зарабатывал от этого мало что поменяется - ну будет у тебя машина чуть круче и квартира чуть больше.
Хм. А что можно приобрести на западе за деньги? Кусок свободы и демократии?
(Ваши слова про нормальную жизнь мне очень даже понятны.)Ответ на сообщение Re: Программист. пользователя Developer
Надо подходить итерационно :). Сравним сначала с г. Москва.
Ага, давайте итерационно. С расчетами по Москве в целом согласен. Продолжу с Европой и США.
...
Получаем, что при зп выше 50 тр из Нска уезжать не выгодно.
1. Европа.
Имеет смысл рассчитывать на 3-3.5 тыс. евро в месяц чистыми на руки.
Минус 1 тыс. евро на съем квартиры, минус неработающая жена. Формально остается 2-2.5 тыс. евро или 80-100 тр. Но учитывая покупательную способность евро, я бы сопоставил эту сумму с новосибирскими 50-60 тр.
То есть реально те же самые 80 тр.
2. США/Канада.
Если оценивать по паритету покупательной способности на уровне 20 рублей за доллар, то $100K превращаются в 2 млн. рублей. Или примерно 150 тр в месяц.
Черт возьми, думаю, здесь на форуме действительно сплошные неудачникиОтвет на сообщение Re: Программист. пользователя nysv
А 100к$ на руки это сколько грязными (с налогами)? Реальная ли столько получать среднестатистическому сфероконному эммигранту?Ответ на сообщение Re: Программист. пользователя Developer
Может оно конечно уже поменялось, но в штатах принято называть зарплату в ГОД, а не месяц... так что 120К$ это гораздо меньше... насколько помню, месячные зарплаты находятся в диапазоне 3-10К$... а аренда жилья была в районе 0.5к .. 2.5к в месяц..."Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин
(а не на "вертикаль власти" надеяться)Исправлено пользователем tolstopuz (07.03.12 12:47)
Ответ на сообщение Re: Программист. пользователя Developer
А 100к$ на руки это сколько грязными (с налогами)? Реальная ли столько получать среднестатистическому сфероконному эммигранту?
Налоги около 30%. У нас, если собрать всё вместе, 35%
- ← предыдущая
- 1 ..
- 9
- 10
- 11
- 12
- 13
- 14
- следующая →
Перейти в форум
Знакомства в Новосибирске
Погода в Новосибирске
Пробки в Новосибирске
Форумы в Новосибирске
Телепрограмма в Новосибирске
Афиша в Новосибирске
Гороскоп
Курсы валют в Новосибирске
Туризм в Новосибирске
Промокоды в Новосибирске
Сетевое издание «НГС.НОВОСТИ» (18+)
Зарегистрировано Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор)
Свидетельство о регистрации СМИ ЭЛ № ФС 77—84683
Учредитель: Общество с ограниченной ответственностью «ИНТЕРНЕТ ТЕХНОЛОГИИ»
Главный редактор: Громкова Елена Александровна
Адрес редакции: 630099, Россия, Новосибирск, ул. Ленина, д. 12, 6 этаж, телефон 8 (383) 212-52-52, 8 (923) 157-00-00 (круглосуточно)
Электронный адрес редакции: ngs@shkulev.ru
Контактные данные для Роскомнадзора и государственных органов: juristnsk@shkulev.ru
Техподдержка: help@shkulev.ru, 8 (800) 200-03-83 (доб.3)
Зарегистрировано Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор)
Свидетельство о регистрации СМИ ЭЛ № ФС 77—84683
Учредитель: Общество с ограниченной ответственностью «ИНТЕРНЕТ ТЕХНОЛОГИИ»
Главный редактор: Громкова Елена Александровна
Адрес редакции: 630099, Россия, Новосибирск, ул. Ленина, д. 12, 6 этаж, телефон 8 (383) 212-52-52, 8 (923) 157-00-00 (круглосуточно)
Электронный адрес редакции: ngs@shkulev.ru
Контактные данные для Роскомнадзора и государственных органов: juristnsk@shkulev.ru
Техподдержка: help@shkulev.ru, 8 (800) 200-03-83 (доб.3)
Связаться с отделом продаж: 8 (383) 212-52-52, 8 (800) 200-03-83 (звонок с сотового бесплатный), reklamangs@shkulev.ru
Публикации с пометкой «На правах рекламы», «Партнёрский проект», «Новости телекома», «Открытая трибуна», «Выборы-2019» и «Выборы-2020» оплачены рекламодателем. Редакция сайта не несет ответственности за достоверность информации, содержащейся в рекламных объявлениях.
Информация об ограничениях
Политика использования cookies
Политика конфиденциальности и обработки персональных данных и правила использования сайта
Публикации с пометкой «На правах рекламы», «Партнёрский проект», «Новости телекома», «Открытая трибуна», «Выборы-2019» и «Выборы-2020» оплачены рекламодателем. Редакция сайта не несет ответственности за достоверность информации, содержащейся в рекламных объявлениях.
Информация об ограничениях
Политика использования cookies
Политика конфиденциальности и обработки персональных данных и правила использования сайта