f1

Криволапые разработчики Яндекс карт под Андроид

Персональное фэ разрабочикам мобильных Яндекс карт для андроида. Суть проблемы в том, что для самсунгов (проверял только на них) есть закладка, что внешняя карта SD будет смонтирована в папку external_sd находящуюся в корне внутренней SD карты (/mnt/sdcard) т.е. /mnt/sdcard/external_sd. Для адроида 2.3 это верно, но никак не для андроида 4.0, где внешняя карточка монтируется как /mnt/emmc и /emmc.

К чему приводит эта закладка (хардкод)? А к тому, что даже если вы в настройках яндекс карт выбираете место для хранения кэша на внешней карте, то один хрен, он будет ВСЕГДА храниться на внутренней карте, просто по другому пути. Таким образом загаживая ценное место.

Все это верно для кастомной прошивки Android 4.0 (Я использую CyanogenMod 9) и возможно в родной стоковой от самсунг, они сделали монтирование в старое место. Для решения проблемы может быть использована как командная строка, с помощью которой можно сделать дополнительный биндинг внешней карты по пути /mnt/sdcard/external_sd, но я использовал ICS SD Binder (требует рута)
f1

Яндекс

В прошлом посте высказал свое персональное фэ яндексу за низкую скорость обновления индекса. Сегодня, опытным путем выяснилось (за вчерашний день резкий взлет посетителей с яндекса), что индекс обновляется раз в 2 недели. Небыстро однако. Да.
f1

Персональное фэ Яндексу

У меня сайт не работал месяц (денег не было заплатить), и естественно он повылетал из всех индексов поисковых систем, но я не об этом сейчас. После восстановления работы сайта, через несколько дней, поток посетителей с гугла восстановился, т.е. сайт нормально восстановился в индексе, а вот у яндекса пока нет и соответственно посетителей оттуда кот наплакал :) Не, с гуглом, с таким тормозным роботом, им конкурировать нельзя.
f1

Оказывается!

Вчера tomash подсказал что на непрогретом двигателе обороты холостого хода повышенные, - а я и не знал :) У меня на непрогретом 1000, а на прогретом в районе 700. Буду теперь знать :)
f1

Прошлый год

Один из самых переменчивых годов у меня получился

  • Отошел от неудачной любви

  • Съездил в Китай

  • Сменил работу

  • Сменил квартиру

  • Сдал на права

  • Купил машину

  • Познакомился с Ниной

Интересно что будет в этом :)
f1

Стив Джобс


  1. Бросил беременную подругу и так и не признает отцовства своей дочери Лизы

  2. До последнего отказывался помогать подруге и ребенку материально. Сделал это только под давлением суда

  3. Людей которых помогали ей в трудную минуту кидал потом

  4. При раздаче акций компании, он послал всех тех кто начинал вместе с ним и акции им не выдавались, зато инженерам которые пришли сильно позже были розданы щедрые пакеты

  5. Мог при решении сложных вопросов расплакаться, будучи уже владельцем компании, - это нужно было для достижения цели любой ценой

  6. Обманывал своих самых близких друзей и коллег - Стива Возняка например, сказав что продал плату или какой-то другой девайс за 500 долларов и отдав ему 300, сам продал её за 1000 и в карман положил себе 700 баксов. Подобные трюки он проделывал постоянно.

  7. При создании Macintosh постоянно занимался микроменеджментом, буквально приходя на место инженера и вмешивался в работу раздавая ему нужные, с его точки зрения, ЦУ, при этом он уже был одним из владельцев Apple с многомилионным состоянием.


Я теперь не удивляюсь почему он не раз терял все и почему его посылали партнеры. Интересно другое, - почему ему до сих пор доверяют люди и почему он выплывает? Изучаю дальше
f1

Бага или фича R#

Наткнулся сегодня на забавное поведение R# при встрече с реальным кодом. Имеем следующий класс:

using System;

namespace tst
{
    public class A<T> where T : IDisposable, new()
    {
        private readonly T _obj;

        public A()
        {
            _obj = new T();
        }

        public void Foo()
        {
            lock (_obj)
            {
                Console.WriteLine(_obj.ToString());
            }
        }
    }

    public struct B : IDisposable
    {
        public void Dispose()
        {
            // implementation
        }
    }
    
    public class C : IDisposable
    {
        public void Dispose()
        {
            // implementation
        }
    }

    internal class Program
    {
        private static void Main()
        {
            A<B> a1 = new A<B>();
            A<C> a2 = new A<C>();
            a1.Foo();
            a2.Foo();
            Console.ReadLine();
        }
    }
}

R# правильно ругается на строчке с lock — действительно экземпляр типа T вполне может оказаться и структурой, а не только классом и таким образом будет нарушено условие для конструкции lock (а точнее для монитора, который эта штука скрывает), т.е. туда передается не ссылочный тип, а размерный. Но код прекрасно компилируется и работает, что не согласуется с теорией. Тут скорее всего идет работа с упакованным в куче объектом структуры, но как это будет работать не очень понятно. Вот и думаю, — бага где, — в R# или C# компиляторе?

Кстати если добавить ещё одно ограничение class, то код перестает компилироваться и правильно:

using System;

namespace tst
{
    public class A<T> where T : class, IDisposable, new()
    {
        private readonly T _obj;

        public A()
        {
            _obj = new T();
        }

        public void Foo()
        {
            lock (_obj)
            {
                Console.WriteLine(_obj.ToString());
            }
        }
    }

    public struct B : IDisposable
    {
        public void Dispose()
        {
            // implementation
        }
    }
    
    public class C : IDisposable
    {
        public void Dispose()
        {
            // implementation
        }
    }

    internal class Program
    {
        private static void Main()
        {
            A<B> a1 = new A<B>();
            A<C> a2 = new A<C>();
            a1.Foo();
            a2.Foo();
            Console.ReadLine();
        }
    }
}

Для себя пришел к выводу, что в таком случае всегда лучше писать class, т.к. поведение, в случае если T структура, может быть неопределенным, т.к. для размерных типов отсутствует такое понятие как индекс синхронизации, на базе которого монитор и работает.
f1

Как улучшить отложенный коммит в TeamCity

В предыдущем посте про отложенный коммит в JetBrains TeamCity, я сказал, что у этого механизма (впрочем, как и у любого другого), есть ограничения, а именно время сборки проекта, при котором этой фичей можно нормально пользоваться. Мне ответили (очевидно, сотрудник JetBrains) что можно пользоваться даже если время сборки большое, нужно просто продолжать работать над другой фичей. Все клево если вы в процессе работы модифицируете другие файлы, ну и если сборка успешная тоже все клево. А если нет? Если вы, работая над другой фичей работаете с теми же самыми файлами, хуже того, правите те же самые строки и до кучи сборка ещё свалилась? Попробуй потом разбери, что к чему относится.

Все это верно в случае использования централизованных систем контроля версий вроде Subversion, где репозиторий централизованный и делая коммит, вы меняете этот репозиторий и все изменения немедленно вступают в силу. Но есть и хорошие новости, — это ограничение можно обойти при использовании распределенной системы контроля версий, вроде Mercurial, Git и пр. Жаль что пока это не поддерживается этой полезной фичей (поддержка отложенного комита сделана только для Subversion и Perforce). Кстати отличный feature request!

В распределенной системе у вас репозиторий локальный, и вы, можете делать сколько угодно коммитов, веток и пр. не нарушая работу других. Т.е. вы используете систему контроля версий по прямому назначению — контролируя все ваши мелкие изменения, при этом никому не мешаете. Кстати, правильное использование распределенной системы контроля версий, позволяет достаточно легко избавиться от вредной привычки коммитить закомментированный код.

После того как вы все сделали, проверили, закоммитили локально, вы делаете push (проталкивание) в репозиторий (назовем его централизованным), из которого проводится сборка продукта и который служит для синхронизации исходников между членами команды. И вот тут то, функция отложенного push была бы очень кстати! Т.е. делается персональная сборка, и если она успешна, то push проходит. Т.к. push делается по определению редко, то можно спокойно ждать пока он завершится работая над другой фичей или багой. Ждем реализации от JetBrains :)

PS: Только называться это уже будет не отложенный коммит, а отложенный пуш и строго говоря, это не улучшение существующей фичи, а реализация другой, но суть дела это не меняет.
f1

Обход каталогов - 2

Как мне правильно сказали, мой первый вариант кода обхода каталогов на Си далеко не идеален. Я поправил все за исключением вынесения обработки ошибок на более высокий уровень. Кроме того, обход каталогов получился все таки не совсем в ширину, но немного модифицированный вариант в глубину, позволяющий держать открытым хэндл только одного каталога, а не всех его родителей.

Collapse )

Спасибо chemodax!
f1

Ограничения отложенного коммита в TeamCity

Есть такая система сборки или постоянной интеграции (кому что нравится), — JetBrains TeamCity. Реально добротно сделанная и идеологически правильная система. Кстати, для маленьких команд версия бесплатна, разумеется с некоторыми ограничениями, которые возможно вам никогда и не понадобятся. Но я не об этом :) Есть в этом продукте одна очень полезная вещь, называемая отложенный коммит (фиксация изменений в системе контроля версий), работающий правда не для всех систем контроля версий и IDE (хотя там есть консольная утиль для этого, но я ей ни разу не пользовался). Что это такое?

Это механизм позволяющий радикально уменьшить количество неудачных сборок из-за несогласованных изменений вносимых в систему контроля версий, из которой потом берутся исходники для сборки продуктов. Как это работает? Очень просто. Разработчик внес изменения в исходный код, собрал, проверил что все работает, но делает фиксацию не сразу, а через специальный штепсель (плугин) для IDE, который берет все локальные изменения, которые он хочет зафиксировать, отправляет их на сервер сборки, сервер сборки соединяет их с кодом из системы контроля версий и начинает сборку. Если сборка (включая Unit тесты, анализ кода, сборку инсталляторов и пр.) проходит успешно, сервер фиксирует в системе контроля версий все изменения, с которыми проводилась эта сборка.

Красиво да? Разумеется, но есть одно существенное ограничение — размер продукта, напрямую влияющий на время сборки. Мы, на моем последнем месте работы (если кто не в курсе, — я ушел из InfoWatch), опытным путем выяснили, что реально пользоваться этим можно только если время сборки не превышает 15-20 минут. Дальше возникает раздражение, желание сделать коммит так, не прибегая к этой функции, т.к. на все время сборки вы выключаетесь из процесса кодирования.

До тех пор пока у нас не было поддержки x64 систем, все укладывалось в эти 20 минут и все было шоколадно. После появления таковой, время сборки выросло до получаса и это стало реально напрягать, поэтому пришлось отключить по умолчанию сборку x64 версии продукта (включается опционально через установку специального свойства при создании задания на сборку). Кстати, с появлением x64 версии, пришлось начать пользоваться precompiled headers (до этого не было, т.к. разработчики считали что эта штука глючит), — тут ещё выиграли минуты 2-3.

Разумеется все вышесказанное касается только "серьезных" коммитов, для мелких, вроде исправления орфографических ошибкок и уж очень очевидных вещей, можно коммитить напрямую, не прибегая к функции отложенного коммита, — просто сэкономите время.