середа, 29 серпня 2012 р.

Андроид - или почему его заслуженно кличут: ведроид (на собственной шкуре)

Этим постом открываю свою серию ругательств на андроид.
К аппарату (самсунг галакси с2б samsung galaxy S II) претензий нет, кроме слабой батарейки и отсутствия внешнего динамика.

Его же ось: андроид это совершенно другое дело! Скайп, хорошая программа. Нa PC, на маке и даже на айфоне. Но не на андроиде. Сегодня она 20 минут отправляла сообщения в никуда при отключенном интернете. Скайп узнал что интернета нет, только когда я попытался позвонить. Сообщения все оказались потерянными разумеется.
Неужели мэнеджмент скайпа набрал отличных ребят чтобы писали для Win, Mac OS X, iOS и полных наркоманов которые программируют скайп под андроид? Слабо верится...
Еще одна проблема: после нажатия sign-in ничего не происходит. Т.е. он начинает логинится на сервера скайпа, но юзер-то об этом не знает! И жмёт кнопку с ужасным раздражением.

Аналогично с фэйсбуком: сегодня фэйсбук апп при отличном нете не смог залить две фотки. Зациклился я его прервал (рестартом девайса, иначе никак) когда он лил 18ую фотку в очереди (состоящую из моих двух).

Жмем кнопку "очистить память" ...

вівторок, 21 серпня 2012 р.

Установка Windows c USB flash с усб флешки

Возможно ли установить виндоус с флешки? ДА. И очень удобно/быстро.
Пора выкидывать USB DVD драйвы.
Правда наверняка биос должен уметь грузиться не только с УСБ ДВД (usb dvd), а еще и с флешки. Но все нынешние без дисководные компьютеры это умеют.

Итак - для начала нам понадобится исошка (.iso) или образ установочного диска системы которую будем ставить.
Еще нужна флешка на 4Gb минимум (на ней еще останется место для файлов / драйверов). На момент написания такая флешка стоила ~50 грн за USB 2.0 и ~80 грн за USB 3.0 (уже на 8Gb)
Качаем http://www.microsoftstore.com/store/msstore/html/pbPage.Help_Win7_usbdvd_dwnTool Запускаем и следуем указаниям визарда (указыванием путь к .iso файлу (может находится в локальной сети)), выбираем флеш драйв на который разоврачивать образ. Ждём. Как закончит - грузимся с флешки и установка идет очень быстро (любая современная флешка быстрее DVD драйва)


Есть еще масса странных способов "ручного" создания загружабельной флешки
http://www.intowindows.com/how-to-install-windows-7vista-from-usb-drive-detailed-100-working-guide/
http://www.maximumpc.com/article/howtos/how_to_install_windows_7_beta_a_usb_key

Но исключительно если по каким-то причинам Windows 7 USB/DVD Download Tool не сработал или есть час та натхнення.

субота, 18 серпня 2012 р.

Радуга и бинокль

Радуга в бинокль видна гораздо хуже!
Глазом очень четко 7 цветов и даже вторая линия видна, в бинокль только три базовых цвета. Сначала думал резкость расстроена - настроил на объекты до радуги и после радуги - все равно 3 цвета

Оптика - великая наука! Кто может объяснить почему так?



пʼятниця, 17 серпня 2012 р.

H.265 стандарт в 2013 году в массах?

h.265 видео энкодер обещает  быть в 2 (два) раза эффективнее h.264 !
Звучит здорово :)

А на практике - вы когда-то видели чтобы следующая версия чего бы-то нибыло было в 2 раза круче?
Я ни разу :)

MSSQL & FullText index & noise words

Бывают применения фул-текст индекса, когда наличие стоп слов больше мешает, чем помогает. Тогда его нужно отключать! :)

В 2008 mssql это делают так:
ALTER FULLTEXT INDEX ON [Content] SET STOPLIST OFF

ALTER FULLTEXT CATALOG [Content] REBUILD
Вуаля. 
А в MSSQL 2005 stop (noise) words отключаются по хитрому: нужно замочить (переименовать) файл со стоп словами. Обычно он лежит:
C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\FTData\noiseENG.txt 
И перестроить индекс
ALTER FULLTEXT CATALOG [Content] REBUILD

вівторок, 14 серпня 2012 р.

nano pad - держалка в машине

GEKKO

На пробу подобрали такой веселый ковричек в эпицентре за 40 грн. Клеется на торпеду легко, снимается без следов, на клей основа не похожа. Субъективно эффект похож на примагничевание шарика к волосам :)
Телефон прикладывается и держится прочно, но снимается на удивление легко. Держатся и не слетают по ухабам очки, бумажки, монеты. 

Кеко на рисунке выглядит стильно :)

Думаю в ванной даже туалетная бумага держалась бы!
Если от жары вонять не будет и через месяц он сам и предметы с него не будут сваливаться - обзаведемся еще двумя-тремя такими же штуками!
gekko.com.ua

понеділок, 6 серпня 2012 р.

Браузер Сафари 6 для виндоуз: Safari 6 for Windows

Браузер сафари 6 для виндоуз не поддерживается. Вот так - однажды майкрософт остановила поддержку офиса для мака (позже правда восстановив её). А сейчас сафари 6 доступен только на Mac OS 10.8 Mountain Lion.

Вообще конечно сафари тормознутый под виндоуз. Очень. Почти как айтюнс..

Safari 6 browser is not supported for Windows. You can download Safari 5 (latest for Windows) here: http://download.cnet.com/Apple-Safari/3000-2356_4-10697481.html?tag=mncol;2

пʼятниця, 3 серпня 2012 р.

Таиланд


тестовое описание фотки

тестовое описание 

Как заставить проэкт VS компилироваться для разных фрэймворков


Есть C#(.NET) утилитная библиотека, которую нужно включать в проекты собираемые под разными .NET версиями. Например в библиотеке есть код использующий .NET Framework v4.0, а нам нужно включить её в проект для .NET 2.0

11 лет .NET фрэймворку будет 13 февраля 2013 года. Было выпущено целых 7 версий. Создано огромное количество программистов. Решено масса задач, концептуально решено огромное число проблем ставящихся перед программистами. 
А вопрос совместимости по прежнему актуален.
Понадобилось мне недавно из набора сырцов разношерстных сырцов слепить библитеку. Как-то устаканить их, влить в коде-базу, сделать все цивилизованно. Код разношерстный, часть использует .NET 4, часть зависит от сборки System.Web и масса кода предназначена только для веба и не имеет смысла в desktop приложении, часть является самописными древними полу-аналогами функционала появившегося в .NET 3-4 и не имеющим смысла для поздних версий фрэймворка. Короче: нужно разделять код, делать условную компиляцию, а главное dll с утилитным кодом не должна требовать наличия фрэймворка выше чем солюшин в который она включена или выше чем проэкт её использующий.
На живом примере: у нас есть класс осуществляющий кеширование объектов в памяти.
  • В случае .NET 4 используем код System.Runtime.Caching и соответственно вносим зависимость на System.Runtime.Caching assembly
  • В случае ASP.NET версии ниже 4.0 используем System.Web.Caching namespace и получаем зависимость на ассемблай
  • В случае desktop приложения для фрэймворка ниже 4.0 используем свой собственный класс (на основе dictionary например)
Последний код скомпилируется везде, но работать будет не так эффективно как первые два и будет менее удобен для программиста. Так как же сделать, чтобы внутри библиотеки был весь этот функционал, но компилятор бы не собирал код и не включал референсы на системные сборки, которые недоступны если мы собираемся для .NET 2.0 например? И включал и использовал функционал для .NET 4 если доступен таковой?

Указание компилятор игнорировать некоторый код у нас идут через директивы препроцессора (кстати, он есть в .NET-e?).
Вспоминаем #define из С/С++ отличная вещь: определяем константы и ветвим код. Замечательно выходит. 
Студия при сборке не определяет константу, подсказывающую компилятору версию фрэймворка. Упс. Ладно определим её сами. 
#define FW3 //если определана эта коснтанта будет включен код которой работает максимум на третьем фрэймворке.
Парням из MS имело бы смысл унифицировать имена подобных констант.
На всякий случай: #define в .NET действует только на тот файл в котором он определен. 
Опять упс. Не сильно удобно. Но идем в настройки проэкта и определяем там константу для препроцессора. Проблема решена?
Нет. Точнее не полностью: мы хардкоднули в проект target framework. Пока у нас dll используется только в одном проекте - всё хорошо. Как только мы начинаем её использовать для разных, приходим к необходимости менять в проекте target framework и переопределять константу для разных солюшенов.

Опытные перцы решают проблему одним из следующих способов:
  1. Держат утилитные классы в отдельной папке и включают всю папку в свой проект (не забыть определить константу для препроцессора).
  2. Держат утилитные классы в отдельной папке и включают всю папку (или файлы по необходимости) в свой локальный проект для солюшена.
  3. Создают несколько проэктных файлов под каждый фрэймворк рядышком использующих один и тот же набор исходников.
  4. Создают билд конфигурации (или схемы) определяющие какой фрэймворк и профайл будет использован для сборки (невозможно через интерфейс VS 2010).
  5. Использовать отдельный солюшин и в другие проекты копировать собранную dll .
  6. Не парится.

Первый вариант: утилитные классы в отдельной папке, которую мы просто закидываем в проект
Плюсы: никакого разбирательства с проектами, удобно дебажить
Минусы: необходимость прописывать для всего солюшена малозначащий дефайн для всего остального кода, пересборка всех сырцов каждый раз (тормозит работу, когда утилитного кода много, а его как правило много), сложности с добавлением новых классов, вероятность повяления дублирующего когда разные программисты изобретают один и тот же велосипед. 
Такой подход благодаря своей простоте хорошо работает в маленькой команде с малым числом проектов. Когда команда разрастается или проекты увеличиваются этот подход создаст больше пробле проблем чем пользы. В итоге одни и теже сырцы будут разнесены, скопированы, продублированы.
Не хорошо..

Вариант второй: утилитные классы в отдельной папке, которую мы просто закидываем в наш солюшин, но уже в отдельный проект.
Почти тоже самое, что случай 1, но более цивилизованно. Уменьшается время сборки для тестового запуска

Третий: несколько проэктных файлов под каждый фрэймворк рядышком использующих один и тот же набор исходников 
Вот это уже совсем по взрослому. Взрослый минус: при изменении файлов в проекте необходимо во всех проэктных файлах лежащих рядом добавить или удалить файлы. Мы программисты любим повторяться? Не-а. Но по всем остальным подходам - это очень правильно и цивилизованно, что избавляет от огромного числа потенциальных будущих проблем (если мы конечно не работаем по принципу: написали, отдали заказчику, забыли)

Четвертый: билд конфигурации определяющие какой фрэймворк и профайл будет использован для сборки 
Один проект, все в одном месте. Даже удобнее, чем третий вариант. В чем подвох? Средствами студии создать такое нельзя. Дожились! 11 лет фрэймворку.
Открываем файл проекта в блокноте и в секции: <PropertyGroup> (та, что для всех) убираем теги: <TargetFrameworkVersion> и таргет схема. 
Далее в каждой проперти группе <PropertyGroup Condition=...> добавляем эти теги сконфигурировав уже как нужно:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'ReleaseFW3|AnyCPU'">
    <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE;FW3</DefineConstants>

Теперь нужно сделать правильный референс к проектам:

  <ItemGroup>
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Runtime.Caching">
<RequiredTargetFramework>4.0</RequiredTargetFramework>
</Reference>
    <Reference Include="System.Web" />
    <Reference Include="System.Xml" />
  </ItemGroup>
Этот код ставит зависимость на System.Runtime.Caching сборку, только если проект компилируется под .NET4




Вариант 5 мне нравится больше всего? А вам?
Правильно: "купание в море повышает настроение" (с) МЕГА. Айда купаться!

Зачем нужен репетитор по математике, если есть учебник?


А кто сказал, что он нужен?

Насколько тяжело должна была даваться выпускникам инфиза математика, что они даже не допускают мысль, что репетитор по математике может быть не нужен?!....

ASP.NET веб сайт: дебаг, релиз и пути ссылок

ASP.NET предлагает замечательную возможность ссылки сразу на виртуальный корень сайта в виде знака ~. Но это работает только для серверной ссылки.

Иногда, по разным причинам требуется, требуется формировать HTML в aspx файле примерно так:
<a href=<%=ServerFormedURL%> title="Супер" ...
В этом случае в ServerFormedURL вставлять '~' нельзя. IIS за нас не проведет подмену части пути. Правильно использовать <asp:HyperLink, но если мы извращенцы и хотим все же сами формировать html?

Как прaвило в интернете сайт находится по пути: http://<domain>/page, в дебаге в локальном ИИС-е либо в ASP.NET development site: http://localhost:<random-port>/virtual-dir/page
где virtual-dir - папка с сайтом.
Таким образом ServerFormedURL должен для локального дебага быть /virtual-dir/page, а для опубликованного релиза на продакшн сервере /page.
Конечно можно в коде написать что-то типа: if(isDebug) return /virtual-dir/page; else return /page; и дебажится на продакшн сервере мы не будем. Но что если на локальном ИИСе потребуется запустить релиз сборку? Правильно ссылки сломаются :(

Я использую примерно такой код:
    private static string GetVirtualDirPrefix()
    {
        if (HttpContext.Current.Server.MachineName.ToLower() == "tukan-7")
            return "/SITE/";
        else
            return "/";
    }