Тут я недавно приобрёл китайский телефон, и задумался о философской проблеме. Вот сколько времени вы привыкаете к телефону? С каких пор, его можно считать своим, основным, любимым и удобным?
Т.к. у меня было достаточно телефонов, то прикинув время привыкания я выяснил, что первые пару недель идёт активное играние с телефоном: настройка под себя, установка программ, импорт контактов и прочее. Телефон почти не вынимается из дата-кабеля (а в последних моделях уже можно сказать что и из зарядки), всё настраивается и перенастраивается. Ещё пару недель идёт использование и небольшое рихтование по мелочам (фотографии к контактам, заливка музыки, тасовка меню, скины).
А потом, я наконец-таки привыкаю к телефону, и он становится родным и удобным девайсом, которым достаточно ненапряжно пользуюсь, и какие-либо изменения идут только случайно: увидел какую-либо информацию, попробовал проверить.
А как у вас? Мучаете ли вы телефоны, или же покупаете, загружаете контакты и начинаете использовать как ни в чём не бывало? Пишите каменты, тут, в твиттере или баззе, мне интересно.
четверг, 27 мая 2010 г.
суббота, 1 мая 2010 г.
Импорт контактов в Outlook
Небольшой хинт по импорту контактов.
Самый дубовый и надёжный способ вытащить контакты с телефона, это запихать их в CSV. Потом их легко можно утащить в тот же Outlook через импорт. В 2010-ом это делается через File, Open, Import, Import from another program or file, Comma Separated Values. Далее выбираете нужный файл, маппите столбцы и радуетесь жизни.
К сожалению, в моём случае, оказалась проблема с русскими именами. Игры с кодировками не принесли результата, в результате получалась или гадость или полная гадость.
Собственно о том, как это исправить: берём Excel, и открываем CSV в нём. Там средства по импорту более развитые, так что результат будет гораздо лучше. Потом делаем Named Range по имортированным данным, сохраняем в xls и делаем в Outlook импорт уже из xls.
Вуаля, всё работает!
воскресенье, 18 апреля 2010 г.
Итоги недели
Ух, ну и неделька выдалась, куча событий, мероприятий и конференций, грех не написать про всё это.
Итак, началась она с того, что в понедельник Microsoft устроила мероприятие посвящённое запуску Visual Studio 2010. Про организацию мероприятия можно писать долго, и в этом будет мало хорошего. Слишком много косяков было, начиная от регистрации, заканчивая отсутствием воды и большим количеством глюков и косяков в самих демонстрациях. Но всё же, мероприятие было весьма полезное. Из него я узнал, что:
Итак, началась она с того, что в понедельник Microsoft устроила мероприятие посвящённое запуску Visual Studio 2010. Про организацию мероприятия можно писать долго, и в этом будет мало хорошего. Слишком много косяков было, начиная от регистрации, заканчивая отсутствием воды и большим количеством глюков и косяков в самих демонстрациях. Но всё же, мероприятие было весьма полезное. Из него я узнал, что:
- В новой Visual Studio сделано много улучшений для разработчиков на C++, обещают что сильно всё переделали, добавили новых API для взаимодействия с новыми фичами
- новый TFS теперь настроен для нормальной работы в небольших проектах с небольшим количеством разработчиков, более шустр и удобен. Можете попробовать.
- Очень хорошие инструменты для тестеров Intellitrace и прочие. Позволяют детально расписать ситуацию с приложением, записать все действия приведшие к ошибки, и даже при желании видео
- Сама студия теперь написана на WPF, и позволяет вести более удобную работу с проектом (быстрый зум, работа с несколькими мониторами). Также стал лучше рефакторинг, но до Resharper'а по-прежнему очень далеко.
В среду мы встретились уже юзергруппой и обсудили рефакторинг, как писать под Windows Phone и что делать с XNA Game Studio. Всё весьма просто и интересно. Если есть желание попробовать, то советую это сделать, нет ничего сложного, а симпатичного результата можно добиться весьма быстро.
В четверг Навжот Павера (если я правильно перевёл его имя), в рамках Opera University Tours рассказывал про круть и мощь Оперы. 
В принципе, особо нового он ничего не рассказал, зато всё было весьма интересно. Опера развивается, любит стандарты и всё такое. Что интересно, ровно на следующий день в Опере таки-пофиксили проблему с Silverlight, когда от приложений на нём опера с грохотом падала. Не знаю, связано или нет, но приятно. Также, как я понял, Опера очень не хочет поддерживать кодек h.264 для тега video, склоняется к Therora или же к гугловому VP8, если тот откроет данный кодек. Также планирует развивать Opera Unite дальше, вплоть до вынесения всего этого в отдельный сервис.
Ну и в пятницу был Microsoft Day для студентов, где рассказывали о новых технологиях Microsoft. Там меня не было, но думаю что тоже было весьма интересно
И вся эта толпа событий в течение одной недели.
В принципе, особо нового он ничего не рассказал, зато всё было весьма интересно. Опера развивается, любит стандарты и всё такое. Что интересно, ровно на следующий день в Опере таки-пофиксили проблему с Silverlight, когда от приложений на нём опера с грохотом падала. Не знаю, связано или нет, но приятно. Также, как я понял, Опера очень не хочет поддерживать кодек h.264 для тега video, склоняется к Therora или же к гугловому VP8, если тот откроет данный кодек. Также планирует развивать Opera Unite дальше, вплоть до вынесения всего этого в отдельный сервис.Ну и в пятницу был Microsoft Day для студентов, где рассказывали о новых технологиях Microsoft. Там меня не было, но думаю что тоже было весьма интересно
И вся эта толпа событий в течение одной недели.
четверг, 8 апреля 2010 г.
Про McHost
Сейчас раскручивается весьма мутная история между Оверсаном и Макхостом (я уже запасся попкорном). Не буду вдаваться в подробности спора двух хозяйствующих субъектов, мне интересно другое.
Макхост всегда был мутным хостингом, даже не зная то, что они кинули Синтерру (или не кинули, опять мутно всё), работать с хостингом у которого на главной странице написано хуй, а в рекламе говорится: "конкурент соси" это как-то на мой взгляд весьма неправильно. Единственное разумное объяснение, зачем там хостится — это низкие цены. Неужели для бизнеса лишние несколько долларов играют такую большую роль? Или я что-то не понимаю.
Сам-то я давно говорил, что с русскими хостерами дела иметь не стоит. И пожар в hosting.ua, история с McHost лишнее тому подтверждение. Есть конечно и другие факторы, что colocation всё-таки удобнее в России делать, и с трафиком для России тоже получше, но, блин, по-моему и без этого можно замечательно прожить, купив хостинг в нормальной стране: где-нибудь в Европе или Америке.
Макхост всегда был мутным хостингом, даже не зная то, что они кинули Синтерру (или не кинули, опять мутно всё), работать с хостингом у которого на главной странице написано хуй, а в рекламе говорится: "конкурент соси" это как-то на мой взгляд весьма неправильно. Единственное разумное объяснение, зачем там хостится — это низкие цены. Неужели для бизнеса лишние несколько долларов играют такую большую роль? Или я что-то не понимаю.
Сам-то я давно говорил, что с русскими хостерами дела иметь не стоит. И пожар в hosting.ua, история с McHost лишнее тому подтверждение. Есть конечно и другие факторы, что colocation всё-таки удобнее в России делать, и с трафиком для России тоже получше, но, блин, по-моему и без этого можно замечательно прожить, купив хостинг в нормальной стране: где-нибудь в Европе или Америке.
воскресенье, 4 апреля 2010 г.
4.04
Сегодня не только Пасха, но и более IT-шный праздник, а именно День Web-программиста. Также празднуют все причастные разработчики, кодеры и верстальщики, в общем все те, кто сталкиваются с вебом. Ну и пользователи могут присоединиться, выпить бутылочку-другую пивка в честь нелёгкого труда программистов.
Сегодня web-разработчики купаются в фонтанах, раскидывают везде теги, пристают к прохожим с вопросами: "Ты под какой браузер верстаешь?", "Пользуешься ли IE6?" и "Что юзаешь, jQuery или табличную вёрстку, ииик?".
К сожалению при попытках выяснить более детальную информацию, я натыкался на полное непонимание со стороны поисковиков, возможно информация об этом дне скрыта и находится под грифом <div style="display: none;"/>, но зато я нашёл, что сегодня ещё день католического святого Исильдора Севильского, который по мнению цекрви сделал первую версию Википедии (или по мнению википедии он сделал первую версию энциклопедии, в общем, тёмно всё). Тем не менее, с 1998-ого года, Исильдор считается покровителем Интернета. Так что поставьте его иконку на важным роутером, назовите в честь него свой DNS-сервер, и в общем, узнайте, не любил ли он звук бубнов и шаманских плясок. Мало ли что.
В общем, ещё раз всех причастных и деепричастных веб-разработчиков:
С профессиональным празднегом!
Сегодня web-разработчики купаются в фонтанах, раскидывают везде теги, пристают к прохожим с вопросами: "Ты под какой браузер верстаешь?", "Пользуешься ли IE6?" и "Что юзаешь, jQuery или табличную вёрстку, ииик?".
К сожалению при попытках выяснить более детальную информацию, я натыкался на полное непонимание со стороны поисковиков, возможно информация об этом дне скрыта и находится под грифом <div style="display: none;"/>, но зато я нашёл, что сегодня ещё день католического святого Исильдора Севильского, который по мнению цекрви сделал первую версию Википедии (или по мнению википедии он сделал первую версию энциклопедии, в общем, тёмно всё). Тем не менее, с 1998-ого года, Исильдор считается покровителем Интернета. Так что поставьте его иконку на важным роутером, назовите в честь него свой DNS-сервер, и в общем, узнайте, не любил ли он звук бубнов и шаманских плясок. Мало ли что.
В общем, ещё раз всех причастных и деепричастных веб-разработчиков:
С профессиональным празднегом!
четверг, 25 марта 2010 г.
Спамеры атакуют
Я достаточно часто получаю спам от всяких вконтактиков, моих миров и прочих одноклассников, о том что %some_strange_person% добавил меня в друзья и мне надо зарегистрироваться на сайте и послать его подальше с такими запросами. Но тут появился спамер, который ещё и обиделся на это: типа я сказал как его зовут, а это типа неправильно (а рассылать такой спам по его мнению это правильно?). Так что специально для него публикую его письмо в своём блоге, пусть обижается дальше.
Так что, желаю удачи спамеру Sasha Shereverov в его нелёгком деле захламления почтовых ящиков дурными сообщениями.
Ваш друг Sasha Shereverov добавил Вас в друзья на сайте http://vkontakte.ru
Вы можете зайти на сайт и просмотреть страницы Ваших друзей, используя
Ваш e-mail и автоматически созданный пароль: t1IPChTaU
ВКонтакте.ру - сайт, который позволяет миллионам людей находить старых
друзей и оставаться с ними на связи, делиться фотографиями
и событиями из жизни.
Чтобы войти на сайт, введите на странице http://vkontakte.ru/login.php
Email, на который Вы получили это приглашение, и пароль: t1IPChTaU
Вы можете изменить пароль в Ваших настройках.
Внимание: Ваша регистрация не будет активирована, если Вы проигнорируете
это приглашение.
Желаем удачи!
Так что, желаю удачи спамеру Sasha Shereverov в его нелёгком деле захламления почтовых ящиков дурными сообщениями.
среда, 24 марта 2010 г.
Перевод времени с точки зрения ИТ-шника
Уже давно идут споры о пользе/вреде летнего времени, хорошо это или плохо, и всё такое. На основных доводах я заострять внимания не буду (хотя и на мой взгляд, смысла особого в наличие перехода нет, а вред уж точно есть). Я хочу немного рассказать о том, какие косяки от этого лезут у программистов, ибо с каждым годом, это всё более актуальнее.
Начнём с простого, время бывает UTC и локальное (если не вдаваться в подробности с атомным временем, и всякими календарями). У UTC есть замечательное свойство: оно течёт постоянно и у всех одно и тоже. Т.е. что у программиста в Америке, что у сурового челябинского админа — цифры одни и те же. Соответственно, по возможности хранить время нужно именно в UTC и использовать при внутренних расчётах именно его, конвертируя его для пользователя при выводе на экран. Но на практике, это оказывается не очень удобным, из-за того, что на всех слоях время необходимо конвертировать, в одну или другую сторону, что может привести к страшной путаницы в самом коде и лишним преобразованиям. При этом для локальных программ, вроде бы это всё не страшно, поэтому UTC можно и не использовать, а в результате получаются разные забавные ситуации:
Как-то работали мы с американским заказчиком, во время очередного билда мы закидывали свежую базу с начальными данными. И всё было хорошо, кроме того что всё падало. Проблема оказалась в том, что сгенерированные данные были в "будущем", и в результате они не находились по фильтру с getdate(). Естественно через 9 часов всё начинало замечательно работать.
Вот небольшой пример того, что может быть, если работать с локальным временем в разных часовых поясах.
Теперь, собственно о переходе на летнее время. Предположим, что у нас есть система мониторинга, которая смотрит живучесть системы раз в минуту, и если она не откликается поднимает тревогу, рестартит приложение, носится с воплями и кричит о том, что всё пропало.
28 марта в 2 часа ночи мгновенно становится 3 часа ночи и по факту система уже не отвечала целый час (!!!) Как результат получим epic fail приложения.
Другой пример: у нас пишутся логи с данными. В последствии мы хотим по ним построить отчёт. Логи длинные, идут годами. Как результат: пишем в UTC, можем получить сдвиг на час в отчёте UTC + Offset который в течение года разный. Пишем в локальном времени: получаем дырку в летнем времени и двойные данные в зимнем (что ещё хуже, если требовать уникальность). В любом случае, ничего хорошего.
Ну и для полноты картины, третий пример, который связан уже с обратным переходом. Представьте себе небольшое кеширование, данные обновляются раз в минуту, в остальных случаях мы просто возвращаем кешированное значение. Когда мы получим два раза по 2 часа ночи, мы в течение целого часа будем сидеть в кеше: надо обновляться когда текущее время больше чем 2:59 + 1, а сейчас опять 2:00. В общем всё просто замечательно выходит.
А теперь представьте, что делать с системами управления ЖД и авиа-транспортом, когда резко поезда с самолётами начинают опаздывать, а вылета в 2:30 в эту ночь не будет. Представьте, сколько может стоить подобная ошибка со временем в программе?
Так что моё мнение, сугубо со стороны программиста: переход на летнее время может повлечь непредсказуемое поведение программы с такими же последствиями. И что самое интересное, а вот фиг это оттестируешь заранее, просто и не вспомнишь об этом.
Начнём с простого, время бывает UTC и локальное (если не вдаваться в подробности с атомным временем, и всякими календарями). У UTC есть замечательное свойство: оно течёт постоянно и у всех одно и тоже. Т.е. что у программиста в Америке, что у сурового челябинского админа — цифры одни и те же. Соответственно, по возможности хранить время нужно именно в UTC и использовать при внутренних расчётах именно его, конвертируя его для пользователя при выводе на экран. Но на практике, это оказывается не очень удобным, из-за того, что на всех слоях время необходимо конвертировать, в одну или другую сторону, что может привести к страшной путаницы в самом коде и лишним преобразованиям. При этом для локальных программ, вроде бы это всё не страшно, поэтому UTC можно и не использовать, а в результате получаются разные забавные ситуации:
Как-то работали мы с американским заказчиком, во время очередного билда мы закидывали свежую базу с начальными данными. И всё было хорошо, кроме того что всё падало.
Проблема оказалась в том, что сгенерированные данные были в "будущем", и в результате они не находились по фильтру с getdate(). Естественно через 9 часов всё начинало замечательно работать.Вот небольшой пример того, что может быть, если работать с локальным временем в разных часовых поясах.
Теперь, собственно о переходе на летнее время. Предположим, что у нас есть система мониторинга, которая смотрит живучесть системы раз в минуту, и если она не откликается поднимает тревогу, рестартит приложение, носится с воплями и кричит о том, что всё пропало.
28 марта в 2 часа ночи мгновенно становится 3 часа ночи и по факту система уже не отвечала целый час (!!!) Как результат получим epic fail приложения.
Другой пример: у нас пишутся логи с данными. В последствии мы хотим по ним построить отчёт. Логи длинные, идут годами. Как результат: пишем в UTC, можем получить сдвиг на час в отчёте UTC + Offset который в течение года разный. Пишем в локальном времени: получаем дырку в летнем времени и двойные данные в зимнем (что ещё хуже, если требовать уникальность). В любом случае, ничего хорошего.
Ну и для полноты картины, третий пример, который связан уже с обратным переходом. Представьте себе небольшое кеширование, данные обновляются раз в минуту, в остальных случаях мы просто возвращаем кешированное значение. Когда мы получим два раза по 2 часа ночи, мы в течение целого часа будем сидеть в кеше: надо обновляться когда текущее время больше чем 2:59 + 1, а сейчас опять 2:00. В общем всё просто замечательно выходит.
А теперь представьте, что делать с системами управления ЖД и авиа-транспортом, когда резко поезда с самолётами начинают опаздывать, а вылета в 2:30 в эту ночь не будет. Представьте, сколько может стоить подобная ошибка со временем в программе?
Так что моё мнение, сугубо со стороны программиста: переход на летнее время может повлечь непредсказуемое поведение программы с такими же последствиями. И что самое интересное, а вот фиг это оттестируешь заранее, просто и не вспомнишь об этом.
Подписаться на:
Сообщения (Atom)
Сообщения
