Открыл для себя очередную группу - Blackfoot Sue. Напоминают, временами, горячо любимых Slade.
Лучшее из того, что я слушал за последнее время.
среда, 27 февраля 2013 г.
ДДУ, 214 ФЗ и прочая непонятная хрень
В начале ноября заключили договор уступки на покупку квартиры по договору долевого участия в строительстве, зарегистрировали в юстиции, посмотрели сроки сдачи 14.01.2013-15.02.2013 и были рады.
16.01.2013 позвонил я застройщику и спросил когда уже ключи будут выдавать. А застройщик мне молвит человеческим голосом - а мы из-за декабрьских морозов (видимо, изначально планировалось в Сочи этот дом строить и особенности температурного режима Сибирского Федерального Округа учтены не были) сроки переносим, давайте заключать дополнительное соглашение к договору о переносе сроков. Я у них спрашиваю - а насколько вы сроки переносите? Они отвечают уклончиво, мол, разрешение на строительство у нас выдано сроком до 31.03.2013, вот к этому времени сдать и должны. Я им сказал, что подумаю.
И подумал я вот что - если они мне сами позвонят и предложат подписать доп. соглашение, то я, пожалуй, не буду выпендриваться - всё-таки к тому что сроки сорвут я был готов. Но они звонить всё не решались и подумал я, что пусть так всё и остаётся. Однако, недавно, где-то 20.02.2013, звонят мне родители и говорят, что на моё имя пришло заказное письмо. Поскольку адрес, при заключении договора, я указывал по прописке (ибо хрен его знает где мы завтра жить будем, а у родителей вроде как стабильность), то подумал, что письмо от застройщика. И вот вчера, 26.02.2013, выяснилось, что был прав.
Получил письмо, а там русским по белому написано, что были произведены замеры квартиры и квартира моя оказалась на 0,7 квадратных метра больше, чем в договоре указано. Т.е. застройщик от меня денюжек на 28,5 тысяч рублей меньше получил, чем хотелось бы. И пишут они, что в течение 20 дней эти деньги они очень бы хотели получить.
А сегодня звонят мне и наивным женским голосом спрашивают когда я буду так добр, что соизволю явиться и подписать доп. соглашение о переносе сроков. Т.е. с меня они деньги хотят в полном объёме получить, а вот за срыв сроков строительства они мне неустойку платить не хотят. В общем, будем смотреть что можно сделать. Вечером надо будет изучить договоры (вчера, увы, не успел) и 214 ФЗ "Об участии в долевом строительстве...", благополучно мной распечатанный.
upd
Сел вечером за изучение ДДУ и договора уступки. В моём ДДУ прописано, что в случае отличия реальной площади от проектной, разница выплачивается либо застройщиком, либо участником долевого строительства, т.е. как и в 214 ФЗ. В интернетах пишут, что обычно добавляется пункт, что такие выплаты не производятся, если реальная площадь отличается меньше чем на 1% от проектной, но у меня этого нет, значит будем платить.
Теперь если дом сдадут не раньше 30.03.2013 - сумма неустойки, которую должен выплатить застройщик за срыв сроков, как раз будет примерно равна сумме которую я им уплачу за доп. площадь. Будем посмотреть.
16.01.2013 позвонил я застройщику и спросил когда уже ключи будут выдавать. А застройщик мне молвит человеческим голосом - а мы из-за декабрьских морозов (видимо, изначально планировалось в Сочи этот дом строить и особенности температурного режима Сибирского Федерального Округа учтены не были) сроки переносим, давайте заключать дополнительное соглашение к договору о переносе сроков. Я у них спрашиваю - а насколько вы сроки переносите? Они отвечают уклончиво, мол, разрешение на строительство у нас выдано сроком до 31.03.2013, вот к этому времени сдать и должны. Я им сказал, что подумаю.
И подумал я вот что - если они мне сами позвонят и предложат подписать доп. соглашение, то я, пожалуй, не буду выпендриваться - всё-таки к тому что сроки сорвут я был готов. Но они звонить всё не решались и подумал я, что пусть так всё и остаётся. Однако, недавно, где-то 20.02.2013, звонят мне родители и говорят, что на моё имя пришло заказное письмо. Поскольку адрес, при заключении договора, я указывал по прописке (ибо хрен его знает где мы завтра жить будем, а у родителей вроде как стабильность), то подумал, что письмо от застройщика. И вот вчера, 26.02.2013, выяснилось, что был прав.
Получил письмо, а там русским по белому написано, что были произведены замеры квартиры и квартира моя оказалась на 0,7 квадратных метра больше, чем в договоре указано. Т.е. застройщик от меня денюжек на 28,5 тысяч рублей меньше получил, чем хотелось бы. И пишут они, что в течение 20 дней эти деньги они очень бы хотели получить.
А сегодня звонят мне и наивным женским голосом спрашивают когда я буду так добр, что соизволю явиться и подписать доп. соглашение о переносе сроков. Т.е. с меня они деньги хотят в полном объёме получить, а вот за срыв сроков строительства они мне неустойку платить не хотят. В общем, будем смотреть что можно сделать. Вечером надо будет изучить договоры (вчера, увы, не успел) и 214 ФЗ "Об участии в долевом строительстве...", благополучно мной распечатанный.
upd
Сел вечером за изучение ДДУ и договора уступки. В моём ДДУ прописано, что в случае отличия реальной площади от проектной, разница выплачивается либо застройщиком, либо участником долевого строительства, т.е. как и в 214 ФЗ. В интернетах пишут, что обычно добавляется пункт, что такие выплаты не производятся, если реальная площадь отличается меньше чем на 1% от проектной, но у меня этого нет, значит будем платить.
Теперь если дом сдадут не раньше 30.03.2013 - сумма неустойки, которую должен выплатить застройщик за срыв сроков, как раз будет примерно равна сумме которую я им уплачу за доп. площадь. Будем посмотреть.
вторник, 26 февраля 2013 г.
24 Hours of PASS. Russian Edition
21-го марта 2013-го года состоится вторая онлайн-конференция "24 Hours of PASS". Необычность этой конференции заключается в том, что она идёт 24 часа (в идеале, у нас 23 часа). Начинается 21-го марта в 00:00 и заканчивается 21-го марта в 23:00. Всего предполагается 23 часовых доклада.
Зарегистрироваться и ознакомиться с программой можно здесь (там же есть ссылки на записи с прошлогодней конференции).
Зарегистрироваться и ознакомиться с программой можно здесь (там же есть ссылки на записи с прошлогодней конференции).
понедельник, 25 февраля 2013 г.
Денис Попов 2.0
Я просто оставлю это здесь.
http://habrahabr.ru/post/170487/
http://sporaw.livejournal.com/153328.html
http://www.anti-malware.ru/forum/index.php?showtopic=25141
http://www.linux.org.ru/forum/talks/8885213/
http://andrewkochetkov.livejournal.com/13569.html
Интересно, в этот раз на ноуты будут предустанавливать антивирус Бабушкина?
http://habrahabr.ru/post/170487/
http://sporaw.livejournal.com/153328.html
http://www.anti-malware.ru/forum/index.php?showtopic=25141
http://www.linux.org.ru/forum/talks/8885213/
http://andrewkochetkov.livejournal.com/13569.html
Интересно, в этот раз на ноуты будут предустанавливать антивирус Бабушкина?
пятница, 22 февраля 2013 г.
Подборка постов по SQL Server за неделю
Подумал, что надо как-то сохранять ссылки на те посты по SQL Server которые меня заинтересовали. Я их, конечно, и так сохранял - отмечал в rss-ридере, но, думаю, так будет удобнее. Плюс, возможно, такая подборка будет интересна кому-то кроме меня. Постараюсь делать такую подборку каждую пятницу (если будет из чего).
1. DBCC WRITEPAGE: an introduction - пост в блоге Paul Randal, о котором я уже написал раньше, поскольку такая возможность действительно меня очень удивила.
2. Corruption demo databases and scripts - пост всё того же Paul Randal который я по непонятным причинам пропустил и наткнулся на него совершенно случайно. По ссылке можно найти как готовые БД, так и скрипты для их создания. Особенность этих БД заключается в том, что все они содержат в себе "повреждения" и их можно использовать для каких либо демонстраций, либо для тренировки.
3. SQL Server statistics questions we were too shy to ask - Grant Fritchey отвечает на множество вопросов, связанных со статистикой в SQL Server
4. SQL Server 2008 Statistics: What does a DBA need to know? - так же посвящён статистике. Matt Bowler рассказывает о том, что с его точки зрения, о статистике должен знать каждый DBA.
5. Troubleshooting and fixing SQL Server page level corruption - Derek Colley объясняет как разобраться с ошибкой "SQL Server detected a logical consistency-based I/O error".
6. 7 Things Developers Should Know About SQL Server - Brent Ozar, бывший разработчик, MCM, администратор баз данных и консультант рассказывает о том, что начинающие разработчики должны учитывать при работе с SQL Server. Перевод этого поста я сделал на хабре.
7. T-SQL script to keep CPU busy - Pinal Dave приводит пример скрипта, позволяющего загрузить CPU на 100% в течение 30-60 секунд.
1. DBCC WRITEPAGE: an introduction - пост в блоге Paul Randal, о котором я уже написал раньше, поскольку такая возможность действительно меня очень удивила.
2. Corruption demo databases and scripts - пост всё того же Paul Randal который я по непонятным причинам пропустил и наткнулся на него совершенно случайно. По ссылке можно найти как готовые БД, так и скрипты для их создания. Особенность этих БД заключается в том, что все они содержат в себе "повреждения" и их можно использовать для каких либо демонстраций, либо для тренировки.
3. SQL Server statistics questions we were too shy to ask - Grant Fritchey отвечает на множество вопросов, связанных со статистикой в SQL Server
4. SQL Server 2008 Statistics: What does a DBA need to know? - так же посвящён статистике. Matt Bowler рассказывает о том, что с его точки зрения, о статистике должен знать каждый DBA.
5. Troubleshooting and fixing SQL Server page level corruption - Derek Colley объясняет как разобраться с ошибкой "SQL Server detected a logical consistency-based I/O error".
6. 7 Things Developers Should Know About SQL Server - Brent Ozar, бывший разработчик, MCM, администратор баз данных и консультант рассказывает о том, что начинающие разработчики должны учитывать при работе с SQL Server. Перевод этого поста я сделал на хабре.
7. T-SQL script to keep CPU busy - Pinal Dave приводит пример скрипта, позволяющего загрузить CPU на 100% в течение 30-60 секунд.
среда, 20 февраля 2013 г.
О пользе первоисточников
Увидел у Вячеслава Гилёва в G+ ссылку на его блог, где он наглядно демонстрирует преимущество "железных" машин над виртуальными. Вот так это выглядело:
На картинках отлично видно, что "железная" машина в два с лишним раза уделывает виртуалку по производительности. Успех, вроде как. Но, вот по ссылке на первоисточник, всё совершенно не так:
Ситуация, конечно, странная, но использовать результаты опыта "наоборот" - это как-то не очень правильно.
upd
На инфостарте нашлось объяснение таким результатам - энергосбережение процессора (к вопросу о вреде этой штуки на серверах, кстати). Теперь результаты как в блоге Гилёва, так и на инфостарте выглядят так:
Виртуалка, как и ожидалось, показывает меньше попугаев, но не в 2 с лишним раза, а практически столько же. Отставание от физической машины незначительное.
Как пишет Вячеслав в своём блоге: "Выводы делайте сами...". :)
Т.е. у человека, проводившего "исследование", виртуалка уделала живую машину, а не наоборот, как говорит об этом Вячеслав.
Ну и ещё один скрин комментов с инфостарта, где автор исследования говорит, что он не ошибся и у него виртуалка действительно работает быстрее (точнее говоря, не виртуалка работает быстрее, а тест показывает больше "попугаев"):
upd
На инфостарте нашлось объяснение таким результатам - энергосбережение процессора (к вопросу о вреде этой штуки на серверах, кстати). Теперь результаты как в блоге Гилёва, так и на инфостарте выглядят так:
Как пишет Вячеслав в своём блоге: "Выводы делайте сами...". :)
понедельник, 18 февраля 2013 г.
SQL Server. DBCC WRITEPAGE. Ещё одна недокументированная функция
Закончив с учёбой и появивишись на работе, добрался до гугл ридера. Там меня ждал вот такой вот пост Пола Рэндала, посвящённый недокументированной DBCC WRITEPAGE (какой-то месяц недокументированных команд SQL Server прям).
Название, в принципе, вполне себе говорящее. Она позволяет "на лету" подправить содержимое ЛЮБОЙ страницы в БД.
Пол говорит, что эта штука может использоваться коммандой SQL Team для починки БД клиента. Плюс с её помощью можно испортить себе БД для тестов, либо наоборот на лету починить повреждённую БД (в том случае если есть полная уверенность в своих действиях).
Синтатксис у неё простой:
dbcc WRITEPAGE ({'dbname' | dbid}, fileid, pageid, offset, length, data [, directORbufferpool])
(
проверить, что синтаксис не отличается от приведённого выше, можно очень просто:
DBCC TRACEON (2588);
GO
DBCC HELP ('WRITEPAGE');
GO
)
, где offset - смещение в байтах относительно начала файла (начало файла = 0), length - длина изменения в байтах (от 1 до 8), data - новые данные для вставки (в 16-м виде, '0xAABBCC' - пример строки длиной три байта), directORbufferpool - должен ли быть задействован buffer pool (да - 0, нет - 1).
Последний параметр очень важен. Если вы укажете, что buffer pool задействовать не нужно, то запись будет произведена непосредственно на диск! Это значит, что SQL Server не пересчитает контрольную сумму, и при попытке чтения изменённой страницы, появится сообщение о повреждении страницы.
Пример такого повреждения можно посмотреть непосредственно в блоге Пола Рэндала, ссылка есть в начале моего поста.
Конечно, такой функционал не должен применяться на рабочем сервере, только на тестовом и в тестовых целях. DBCC WRITEPAGE может стать ещё одним способом выстрелить себе в ногу, при попытке использовать его на рабочей базе, не до конца осознавая собственные действия.
Название, в принципе, вполне себе говорящее. Она позволяет "на лету" подправить содержимое ЛЮБОЙ страницы в БД.
Пол говорит, что эта штука может использоваться коммандой SQL Team для починки БД клиента. Плюс с её помощью можно испортить себе БД для тестов, либо наоборот на лету починить повреждённую БД (в том случае если есть полная уверенность в своих действиях).
Синтатксис у неё простой:
dbcc WRITEPAGE ({'dbname' | dbid}, fileid, pageid, offset, length, data [, directORbufferpool])
(
проверить, что синтаксис не отличается от приведённого выше, можно очень просто:
DBCC TRACEON (2588);
GO
DBCC HELP ('WRITEPAGE');
GO
)
, где offset - смещение в байтах относительно начала файла (начало файла = 0), length - длина изменения в байтах (от 1 до 8), data - новые данные для вставки (в 16-м виде, '0xAABBCC' - пример строки длиной три байта), directORbufferpool - должен ли быть задействован buffer pool (да - 0, нет - 1).
Последний параметр очень важен. Если вы укажете, что buffer pool задействовать не нужно, то запись будет произведена непосредственно на диск! Это значит, что SQL Server не пересчитает контрольную сумму, и при попытке чтения изменённой страницы, появится сообщение о повреждении страницы.
Пример такого повреждения можно посмотреть непосредственно в блоге Пола Рэндала, ссылка есть в начале моего поста.
Конечно, такой функционал не должен применяться на рабочем сервере, только на тестовом и в тестовых целях. DBCC WRITEPAGE может стать ещё одним способом выстрелить себе в ногу, при попытке использовать его на рабочей базе, не до конца осознавая собственные действия.
Подписаться на:
Сообщения (Atom)