Буду собирать ссылки на RIA
пятница, 31 августа 2007 г.
среда, 29 августа 2007 г.
Еще о базах данных - идеальный package manager
См. также 2 часть размышлений об идеальном package manager.
Вот эта вот дискуссия у Бескова -- напомнила мне о всех тех ужасах, которые я переживаю при думании о поддержке баз данных.
В жизненном цикле ПО, особенно серверного, базе данных отведено отдельное место
* БД почти всегда обновляется, и почти никогда не ставится с нуля. Исключение -- только установка новых инсталляций продукта
* Я не знаю никаких встроенных в известные RDBMS инсталляторов схемы - с инкрементальными патчами, версиями модулей и т д. А их очень не хватает
В минимальном виде идеальный package manager должен уметь делать следующее
* вести помодульный реестр установленных в БД компонентов
* позволять инсталлировать/деинсталлировать модули.
* вести зависимость между модулями.
* позволять установить БД "с нуля", накатывая патч за патчем до определенной версии
* инсталляционные скрипты должны быть в виде .sql-файлов (желательно)
В идеале, система должна иметь одинаковый интерфейс под всеми RDBMS.
Может быть, пришло время для какого-нибудь DB Maven? :)
PS: несколько ссылок
* http://www.agiledata.org/essays/tools.html
* http://autopatch.sourceforge.net/documentation.php
* http://migratedb.sourceforge.net/
UPD от 13 Cен: http://www.liquibase.org
UPD 19 янв 09:
* http://db.apache.org/ddlutils/index.html
UPD 9 авг 09:
Подборка относительно недавних проектов, привносящих в .Net мир ruby style migrations
UPD 9 авг 09:
Подборка относительно недавних проектов, привносящих в .Net мир ruby style migrations
- http://www.rikware.com/RikMigrations.html
- http://code.google.com/p/migratordotnet
- http://code.google.com/p/octalforty-wizardby
Интересная дискуссия в ru_pm - "как управлять Гуру"
http://community.livejournal.com/ru_pm/69294.html
"В нашей компании есть несколько человек со статусом - "мега эксперт"! ;)Это такие звезды, которые больше всех знают по специфике и работают в компании от самой ее основания.И естественно, ведут себя они как самые настоящие звезды, то есть - почти не управляемые. Вокруг них "на цыпочках" - ходят даже руководители департамента, и нам, руководителям проекта, с ними очень тяжело.Лично мне - проще их выгнать или просто с ними не работать на проектах, но на такое наше руководство не пойдет.Но что можно сделать с ними, кроме уговоров?:)"
Собственно, и не дискуссия даже -- все бъют в одни ворота. Дайте Гуру возможности раскрыть потенциал, не ссорьтесь с ним, требуйте внятных результатов и обставьте помошниками.
Вообще, я как побывавший отчасти в обоих :) ролях, попробую описать чувства как менеджера, так и этого самого Гуру.
Как эксперт в какой-то области - тут главное не потерять адекватность. Потому что тебе дают самые "вкусные" куски работы (точнее, ты сам выбираешь вобщем-то, за что браться). Лично для меня медными трубами было ощущение, что один я занимаюсь нужными делами, а остальные .. не очень :) Лечится пониманием того, что все сам один в реальные сроки сделать не успеешь, а если успеешь - возненавидишь белый свет и проект и все-все-все...
Менеджер в этом случае нужен как добрый помошник, который планирует твое время, ставит тебе приоритеты "от бизнеса" и выделяет допресурсы, если такие нужны. Когда твое время планируют "тут ты 3 часа копаешь туда, потом 6 часов - сюда". Офигенно удобно - ты копаешь, концентрируешься на тактике, а некий человек, как в Матрице, говорит "Operator!" и советует, куда дальше двигаться
С точки зрения менеджера (в моем случае - технического лида, планирующего работу других людей), эксперт -- существо несколько раздражающее, но при этом не дающее расслабиться. Эффективность его обычно высока (хотя могут случаться неожиданные "провалы") и любую работу он делает если не быстрее, то как минимум раз в 5 лучше любого своего коллеги. Если "зажечь" такого эксперта интересной задачей - он будет сидеть днями и ночами, и ее решать. Результатом может быть шедевр. Но если не кормить Эксперта вкусными задачами, то он начинает портиться и негативно влиять на остальных. Например, приходить на работу в середине дня часа на 4...
Как-то так. Мне в роли менеджера было сложнее, думаю, потому что очень хотелось поддерживать внутри иллюзию, что ты сейчас скажешь, как делать -- и все так и случится. Ан нет. На самом деле, менеджер -- он как дирижер. Без него оркестр не заиграет, но и сам по себе он ничего сделать не сможешь.
"В нашей компании есть несколько человек со статусом - "мега эксперт"! ;)Это такие звезды, которые больше всех знают по специфике и работают в компании от самой ее основания.И естественно, ведут себя они как самые настоящие звезды, то есть - почти не управляемые. Вокруг них "на цыпочках" - ходят даже руководители департамента, и нам, руководителям проекта, с ними очень тяжело.Лично мне - проще их выгнать или просто с ними не работать на проектах, но на такое наше руководство не пойдет.Но что можно сделать с ними, кроме уговоров?:)"
Собственно, и не дискуссия даже -- все бъют в одни ворота. Дайте Гуру возможности раскрыть потенциал, не ссорьтесь с ним, требуйте внятных результатов и обставьте помошниками.
Вообще, я как побывавший отчасти в обоих :) ролях, попробую описать чувства как менеджера, так и этого самого Гуру.
Как эксперт в какой-то области - тут главное не потерять адекватность. Потому что тебе дают самые "вкусные" куски работы (точнее, ты сам выбираешь вобщем-то, за что браться). Лично для меня медными трубами было ощущение, что один я занимаюсь нужными делами, а остальные .. не очень :) Лечится пониманием того, что все сам один в реальные сроки сделать не успеешь, а если успеешь - возненавидишь белый свет и проект и все-все-все...
Менеджер в этом случае нужен как добрый помошник, который планирует твое время, ставит тебе приоритеты "от бизнеса" и выделяет допресурсы, если такие нужны. Когда твое время планируют "тут ты 3 часа копаешь туда, потом 6 часов - сюда". Офигенно удобно - ты копаешь, концентрируешься на тактике, а некий человек, как в Матрице, говорит "Operator!" и советует, куда дальше двигаться
С точки зрения менеджера (в моем случае - технического лида, планирующего работу других людей), эксперт -- существо несколько раздражающее, но при этом не дающее расслабиться. Эффективность его обычно высока (хотя могут случаться неожиданные "провалы") и любую работу он делает если не быстрее, то как минимум раз в 5 лучше любого своего коллеги. Если "зажечь" такого эксперта интересной задачей - он будет сидеть днями и ночами, и ее решать. Результатом может быть шедевр. Но если не кормить Эксперта вкусными задачами, то он начинает портиться и негативно влиять на остальных. Например, приходить на работу в середине дня часа на 4...
Как-то так. Мне в роли менеджера было сложнее, думаю, потому что очень хотелось поддерживать внутри иллюзию, что ты сейчас скажешь, как делать -- и все так и случится. Ан нет. На самом деле, менеджер -- он как дирижер. Без него оркестр не заиграет, но и сам по себе он ничего сделать не сможешь.
воскресенье, 26 августа 2007 г.
Древовидная БД - Как перестроить уровни ветвей
Допустим, нам дана следующая таблица, хранящая дерево категорий:
CREATE TABLE [dbo].[Categories](
[CategoryId] [int] IDENTITY(1,1) NOT NULL,
[CategoryName] [nvarchar](250) NOT NULL,
[ParentId] [int] NULL,
[Level] [int] NOT NULL,
CONSTRAINT [PK_Categories] PRIMARY KEY CLUSTERED
(CategoryId] ASC)
)
В таблице хранятся категории со ссылкой на родителя и их уровень. Уровень корня будет равен 1. Мы вводим уровень, для того, чтобы затем удобно строить дерево категорий в HTML.
Очевидно, нам потребуется какой-то путь автоматического расчета уровней для дерева категорий.
Например, это можно сделать такой вот процедурой:
CREATE PROCEDURE CatRebuildLevels
AS
BEGIN
DECLARE @CLevel int;
set @CLevel=1;
UPDATE Categories SET [Level]=0 WHERE NOT ParentId IS NULL;
UPDATE Categories SET [Level]=1 WHERE ParentId IS NULL;
WHILE (SELECT COUNT(*)
FROM Categories C
INNER JOIN Categories PC
ON PC.CategoryId=C.ParentId
WHERE PC.[Level] = @CLevel) > 0
BEGIN
UPDATE Categories
SET Categories.[Level]=@CLevel+1
WHERE CategoryId IN
(SELECT C.CategoryId
FROM Categories C
INNER JOIN Categories PC
ON C.ParentId = PC.CategoryId
WHERE
PC.[Level] = @CLevel)
set @CLevel = @CLevel+1
END
END
Общая идея - проставлять рекуррентно уровень, начиная с единицы. Каждый следующий уровень будет на 1 больше, чем предыдущий. Совсем несложно адаптировать эту процдуру для триггеров.
CREATE TABLE [dbo].[Categories](
[CategoryId] [int] IDENTITY(1,1) NOT NULL,
[CategoryName] [nvarchar](250) NOT NULL,
[ParentId] [int] NULL,
[Level] [int] NOT NULL,
CONSTRAINT [PK_Categories] PRIMARY KEY CLUSTERED
(CategoryId] ASC)
)
В таблице хранятся категории со ссылкой на родителя и их уровень. Уровень корня будет равен 1. Мы вводим уровень, для того, чтобы затем удобно строить дерево категорий в HTML.
Очевидно, нам потребуется какой-то путь автоматического расчета уровней для дерева категорий.
Например, это можно сделать такой вот процедурой:
CREATE PROCEDURE CatRebuildLevels
AS
BEGIN
DECLARE @CLevel int;
set @CLevel=1;
UPDATE Categories SET [Level]=0 WHERE NOT ParentId IS NULL;
UPDATE Categories SET [Level]=1 WHERE ParentId IS NULL;
WHILE (SELECT COUNT(*)
FROM Categories C
INNER JOIN Categories PC
ON PC.CategoryId=C.ParentId
WHERE PC.[Level] = @CLevel) > 0
BEGIN
UPDATE Categories
SET Categories.[Level]=@CLevel+1
WHERE CategoryId IN
(SELECT C.CategoryId
FROM Categories C
INNER JOIN Categories PC
ON C.ParentId = PC.CategoryId
WHERE
PC.[Level] = @CLevel)
set @CLevel = @CLevel+1
END
END
Общая идея - проставлять рекуррентно уровень, начиная с единицы. Каждый следующий уровень будет на 1 больше, чем предыдущий. Совсем несложно адаптировать эту процдуру для триггеров.
вторник, 21 августа 2007 г.
Обсуждение на RSDN - "Как найти и удержать программиста"
http://www.rsdn.ru/forum/message/2628646.aspx
"Столкнулся с ситуацией — приходит человек на работу, работает какое-то время, потом уходит, мотивируя тем, что работа ведется не по классическим технологиям, техзадания неконкретные, код не по Макконелу, архитектура не по паттернам проектирования и вообще, мол, хочу в крупную компанию.
Да, действительно, мы не используем в работе никакой из современный методологий разработки ПО; да, формализация задач слабая; да, работа не вполне регламентирована и упорядочена. Но надо же четко понимать, что москва не сразу строилась и все такое. Любая компания начинала с комнатки в нии и два разработчика за пыльным столом...."
Мысли противоречивые. Формулировать как-то особенно не хочется. Но мне кажется, им нужен свежий взгляд со стороны
"Столкнулся с ситуацией — приходит человек на работу, работает какое-то время, потом уходит, мотивируя тем, что работа ведется не по классическим технологиям, техзадания неконкретные, код не по Макконелу, архитектура не по паттернам проектирования и вообще, мол, хочу в крупную компанию.
Да, действительно, мы не используем в работе никакой из современный методологий разработки ПО; да, формализация задач слабая; да, работа не вполне регламентирована и упорядочена. Но надо же четко понимать, что москва не сразу строилась и все такое. Любая компания начинала с комнатки в нии и два разработчика за пыльным столом...."
Мысли противоречивые. Формулировать как-то особенно не хочется. Но мне кажется, им нужен свежий взгляд со стороны
понедельник, 20 августа 2007 г.
Почему упал Skype
Так понимаю, вот официальная версия skype, почему их упало на два дня.
http://www.appscout.com/2007/08/skype_user_re-boot_prompted_system_outage.php
"VoIP provider Skype said Sunday that its network was "back to normal" after several days of sign-in difficulties. The company blamed a "massive restart" of user computers that occurred after a "routine set of patches" from Windows Update required users to re-boot their computers."
То есть: Microsoft выпустила обновление, которое после того, как установилось на клиентские компьютеры, потребовало перезагрузки. И многие миллионы пользователей skype примерно одновременно перезагрузили свои машины, после чего их skype-клиенты полезли коннектиться. Сервера skype, видимо, не выдержали нагрузки и рухнули.
А дальше, по какой-то причине, пул не могли перестартовать 2 дня...
То есть выглядит так, что у skype процесс логина -- это ресурсоемкая, с точки зрения серверов, операция. Это понятно, это так много где. Например, в том же Агенте mail.ru есть фишка - если сервер, к которому подключен клиент, перестает отвечать, то клиент ждет случайно от 1 до 10 секунд и только потом лезет конектиться. Этим "размазывают" колну коннектящихся клиентов и серверам проще ее перенести.
Не очень понятно правда, почему он 2 дня его потом поднимали...
Обсуждение на ru_highload: http://community.livejournal.com/ru_highload/18482.html?mode=reply
http://www.appscout.com/2007/08/skype_user_re-boot_prompted_system_outage.php
"VoIP provider Skype said Sunday that its network was "back to normal" after several days of sign-in difficulties. The company blamed a "massive restart" of user computers that occurred after a "routine set of patches" from Windows Update required users to re-boot their computers."
То есть: Microsoft выпустила обновление, которое после того, как установилось на клиентские компьютеры, потребовало перезагрузки. И многие миллионы пользователей skype примерно одновременно перезагрузили свои машины, после чего их skype-клиенты полезли коннектиться. Сервера skype, видимо, не выдержали нагрузки и рухнули.
А дальше, по какой-то причине, пул не могли перестартовать 2 дня...
То есть выглядит так, что у skype процесс логина -- это ресурсоемкая, с точки зрения серверов, операция. Это понятно, это так много где. Например, в том же Агенте mail.ru есть фишка - если сервер, к которому подключен клиент, перестает отвечать, то клиент ждет случайно от 1 до 10 секунд и только потом лезет конектиться. Этим "размазывают" колну коннектящихся клиентов и серверам проще ее перенести.
Не очень понятно правда, почему он 2 дня его потом поднимали...
Обсуждение на ru_highload: http://community.livejournal.com/ru_highload/18482.html?mode=reply
понедельник, 13 августа 2007 г.
пятница, 10 августа 2007 г.
Использую, но не люблю
Понял, чем не нравятся скринкасты - их нельзя читать по-диагонали. Отсюда - тратится больше времени.
Хотя в работе скринкасты использую постоянно - вместо того, чтобы потратить 2 часа на написание документа, можно за 10 минут сделать скринкаст.
Хотя в работе скринкасты использую постоянно - вместо того, чтобы потратить 2 часа на написание документа, можно за 10 минут сделать скринкаст.
суббота, 4 августа 2007 г.
Не забыть! проект subsonic
http://www.subsonicproject.com/ - очередной DAL framework, в этот раз базированный на Ruby on Rails. Надо посмотреть, что там ребята наворотили...
"What is it?
A Super High-fidelity Batman Utility Belt. SubSonic works up your DAL for you, throws in some much-needed utility functions, and generally speeds along your dev cycle."
"What is it?
A Super High-fidelity Batman Utility Belt. SubSonic works up your DAL for you, throws in some much-needed utility functions, and generally speeds along your dev cycle."
Подписаться на:
Сообщения (Atom)
