На Космос ТВ появились новые тарифы - метеор и комета. Вкратце, предлагают в 4 раза больше трафика за те же деньги - 16 GB за 50 тысяч вместо 4GB за 55. Шуму особенно не поднимают, если бы я случайно не наткнулся, то так бы и сидел на оптимальном.
Скорее всего, следствие снижения цен Белтелекомом для провайдеров, монополия во всей её красе. Похоже, такой же реакции стоит вскоре ожидать и от других провайдеров, поэтому советую следить за новостями. И да, пишут, что в ноябре планируют еще одно снижение.
среда, 21 июля 2010 г.
понедельник, 19 июля 2010 г.
Round Robin
Те, кто занимаются оптимизацией производительности, знают, что round robin это простейший способ распределения данных между потоками обработки. В нашей команде за этим понятием прочно закрепился и другой смысл – честное распределение рутинной работы между членами команды.
пятница, 16 июля 2010 г.
Production Clone
Банал-баналом, однако, почему-то в реальности никто так не делает, мучает людей жадность. Ну, знайте же, что жадность эта боком выходит.
пятница, 9 июля 2010 г.
Akavita и Белтелеком
Зашел давеча на http://www.akavita.by/, думаю, добавлю себя в каталог их или там счетчик возьму, а браузер мне и говорит:
В связи с отключением питания в дата-центре предприятием Белтелеком, частично повреждена база данных. Ведутся восстановительные работы. Приносим извинения за неудобства...Сочуствую. Вот она вам государственная монополия. Примечательно, что вчера у них вместо PS было что-то вроде !@#$%^&* - я считаю, гораздо более эмоциональное заявление :)
PS:
Коллектив "Акавиты" выражает глубокое сожаление, что Белтелеком, выполняя роль главного сайторазмещателя страны, не видит разницы между энергоснабжением дата-центра и картофелехранилища (дескать, ночью не жарко, картошка и не испортится).
Странное мероприятие под названием "плановое отключение электричества в дата-центре" (на четверть суток!) ярко характеризует отношение к белорусскому интернету и IT-индустрии в целом.
среда, 7 июля 2010 г.
Ab Initio ETL
Чтобы не расстраивать тех, кто приходит ко мне по запросу в сабже, расскажу пару слов о том, что я знаю про Ab Initio, а знаю я чуть больше, чем просто то, что это дорогостоящая, очень быстрая и засекреченная ETL платформа. Каких-то больших секретов я вам не открою, однако мои впечатления вам могут быть вполне интересны.
понедельник, 5 июля 2010 г.
Stop rolling your own CSV parser
Your own CSV parser
Вот именно такую заметку я нашел, когда пытался подыскать подходящую версию CSV парсера для нашего приложения, - Stop Rolling Your Own CSV Parser.
Каждое предложение было до боли знакомо - после безуспешных попыток привести код в приемлемое состояние, захотелось все же воспользоваться готовым решением. Читая заметку, я был согласен с автором на 100%.
Дальнейший анализ все же показал, что не все так просто.
Вот именно такую заметку я нашел, когда пытался подыскать подходящую версию CSV парсера для нашего приложения, - Stop Rolling Your Own CSV Parser.
Каждое предложение было до боли знакомо - после безуспешных попыток привести код в приемлемое состояние, захотелось все же воспользоваться готовым решением. Читая заметку, я был согласен с автором на 100%.
Дальнейший анализ все же показал, что не все так просто.
пятница, 2 июля 2010 г.
Data Quality
Читаю сейчас Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior. Интересная книга, советую.
Книга
Книга состоит из 86 эссе про хорошие и плохие вещи, повсеместно происходящие на проектах. Это скорее эссе, а не паттерны, к которым мы привыкли по GoF. Точнее мы приближаемся ближе к первоначальному значению слова "паттерн" - в данном контексте нечто повторяющееся от одного проекта к другому, неважно - плохо это или хорошо.
К слову, "плохих" историй больше, чем хороших. Оно и понятно, ведь по Chaos Report, заваленных проектов больше, чем успешных. С хорошими паттернами все ясно - бери и пользуй. Плохие скорее похожи на диагнозы без четко определенного курса лечения. В некоторых случаях прямо в лоб нам сообщают, что не лечится, иногда все же есть анализ и советы, как избежать таких ситуаций. Хотя в большинстве случаев просто объясняются возможные причины - а решение проблемы остается за вами.
Data Quality
Один из (анти)паттернов, очень близкий к моим профессиональным интересам, - Data Quality.
В одно предложение - "Качество данных оставляет желать лучшего, но вместо того, чтобы исправить сами данные, мы сделаем приложение, которое может работать с этими данными, автоматически исправлять, валидировать, пережевывать любые проблемы".
Звучит неплохо, почему бы и нет. Действительно, вместо того, чтобы исправить 5 миллионов неправильных телефонов вручную, проще сделать приложение, которые будет проверять правильность (или корректность номера) и неким образом исправлять ситуацию.
Это сложно
Именно так:
0. Сложно определить - правильные данные или нет
1. Исправить неправильные данные сложно
2. Еще сложнее сделать это автоматически
3. Правильно исправить неправильные данные - совсем тяжело
4. Правильно исправленные данные скоро могут стать неправильными
5. Если вы исправляете данные за ваших поставщиков, поставщики данных поставляют вам все более неправильные данные
6. Если вы исправляете данные в принципе, то все неправильные данные, которые приходят из вашего приложения - это ошибки в вашем приложении
Самое противное - это последние два пункта. По сути, вы снимаете ответственность за правильность данных с поставщика и потребителя и берете эту ответственность на себя. Это бесконечный scope, бесконечный источник багов и уникальная возможность для поставщиков и потребителей свалить на вас их проблемы.
Медвежья услуга
Это похоже на глотание exceptions. Если вы проглотили exception, то вы спрятали ошибку. Ошибка все еще существует. Когда к вам придут и скажут - у вас здесь неправильно, то вы только можете надеяться, что сможете когда-либо выйти на истинную причину ошибки. Ведь вы её сами же маскируете, проглатывая некорректные данные.
Или представьте себе, что вы наняли программиста, который делает ошибки в коде и вам за него надо их исправлять. Возникает два вопроса: почему и доколе. Ответы просты: "потому что за него исправляли ошибки и ранее" и "пока вы будете исправлять за ним ошибки, ничего не изменится". Точнее изменится, но в худшую сторону.
По сути, сами неправильные данные получаются благодаря тому, что данные толерантно воспринимаются потребителями.
Это замкнутый круг, а по-русски - медвежья услуга. Ведь приложения - они как люди, а если человек - тряпка, то все будут понукать им. Так что пишите только дерзкий код. Пусть он лучше дерзит вам прямо в лицо, но говорит только правду.
Книга
Книга состоит из 86 эссе про хорошие и плохие вещи, повсеместно происходящие на проектах. Это скорее эссе, а не паттерны, к которым мы привыкли по GoF. Точнее мы приближаемся ближе к первоначальному значению слова "паттерн" - в данном контексте нечто повторяющееся от одного проекта к другому, неважно - плохо это или хорошо.
К слову, "плохих" историй больше, чем хороших. Оно и понятно, ведь по Chaos Report, заваленных проектов больше, чем успешных. С хорошими паттернами все ясно - бери и пользуй. Плохие скорее похожи на диагнозы без четко определенного курса лечения. В некоторых случаях прямо в лоб нам сообщают, что не лечится, иногда все же есть анализ и советы, как избежать таких ситуаций. Хотя в большинстве случаев просто объясняются возможные причины - а решение проблемы остается за вами.
Data Quality
Один из (анти)паттернов, очень близкий к моим профессиональным интересам, - Data Quality.
В одно предложение - "Качество данных оставляет желать лучшего, но вместо того, чтобы исправить сами данные, мы сделаем приложение, которое может работать с этими данными, автоматически исправлять, валидировать, пережевывать любые проблемы".
Звучит неплохо, почему бы и нет. Действительно, вместо того, чтобы исправить 5 миллионов неправильных телефонов вручную, проще сделать приложение, которые будет проверять правильность (или корректность номера) и неким образом исправлять ситуацию.
Это сложно
Именно так:
0. Сложно определить - правильные данные или нет
1. Исправить неправильные данные сложно
2. Еще сложнее сделать это автоматически
3. Правильно исправить неправильные данные - совсем тяжело
4. Правильно исправленные данные скоро могут стать неправильными
5. Если вы исправляете данные за ваших поставщиков, поставщики данных поставляют вам все более неправильные данные
6. Если вы исправляете данные в принципе, то все неправильные данные, которые приходят из вашего приложения - это ошибки в вашем приложении
Самое противное - это последние два пункта. По сути, вы снимаете ответственность за правильность данных с поставщика и потребителя и берете эту ответственность на себя. Это бесконечный scope, бесконечный источник багов и уникальная возможность для поставщиков и потребителей свалить на вас их проблемы.
Медвежья услуга
Это похоже на глотание exceptions. Если вы проглотили exception, то вы спрятали ошибку. Ошибка все еще существует. Когда к вам придут и скажут - у вас здесь неправильно, то вы только можете надеяться, что сможете когда-либо выйти на истинную причину ошибки. Ведь вы её сами же маскируете, проглатывая некорректные данные.
Или представьте себе, что вы наняли программиста, который делает ошибки в коде и вам за него надо их исправлять. Возникает два вопроса: почему и доколе. Ответы просты: "потому что за него исправляли ошибки и ранее" и "пока вы будете исправлять за ним ошибки, ничего не изменится". Точнее изменится, но в худшую сторону.
По сути, сами неправильные данные получаются благодаря тому, что данные толерантно воспринимаются потребителями.
Это замкнутый круг, а по-русски - медвежья услуга. Ведь приложения - они как люди, а если человек - тряпка, то все будут понукать им. Так что пишите только дерзкий код. Пусть он лучше дерзит вам прямо в лицо, но говорит только правду.
Подписаться на:
Сообщения (Atom)