MacOSX: Unicode в названиях файлов в HFS

Недавно, я столкнулся с тем что Git на свежевыкачанном репозитории SVN упорно считает, что некоторые файлы находятся в состоянии Untracked.

Небольшое расследование вывело на следующее.

Unicode позволяет, если не совсем избавиться, то минимизировать проблемы национальных кодировок.

Большое число символов задаётся одним единственным кодом.

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

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

Кириллица не стала исключением.

При создании файлов, содержащих в наименовании композитные буквы, HFS сохраняет эти названия в виде двух отдельных знаков.

Для меня это стало сюрпризом, т.к. хотя по спецификации всё верно: буква "Й" является композицией следующих двух:

www.fileformat.info/info/unicode/char/0438/index.htm

www.fileformat.info/info/unicode/char/0306/index.htm

Тем не менее, буква имеет и единичный код

www.fileformat.info/info/unicode/char/0439/index.htm

Аналогично и для "Ё".

Если невооружённым взглядом такое поведение или сложно или невозможно, то оно прекрасно наблюдается во время SSH-сессии.

Локально из терминала проблему можно воспроизвести если создать какой-либо файл, например:

$ touch Ё-моё.txt

И попровать затем выполнить автодополение клавишей [TAB].

$ ./Ё[TAB]

не срабатывает.

Но если ввести

$ ./Е[TAB]

то мы увидим нашу многострадальную "Ё".

Некоторые программы (в моём случае GIT и SVN) не могут корректно обработать такую ситуацию.

Файл, по-мнению алгоритмов, просто не существует.

То есть один и тот же файл в репозитории (попавший туда из других файловых систем) и хранящийся локально (в HFS) считается двумя разными файлами.

Пока мне не попалось подходящего решения или обходного пути.

И, похоже, что необходимо заводить тикет с багой.


Далее, можно почитать про проблему длинных имён в HFS+

Автоматическая выгрузка SMS в Google Docs

На телефоне скопилось слишком много смс и большая часть из них лежит просто мёртвым грузом.

Но иногда мне требуется ретроспектива (по банковской информации, например), поэтому удалять жалко.

Я подумал, что было бы неплохо, если бы смс автоматически загружались в GoogleDocs, а на телефоне оставались только относительно недавние сообщения.

Поиски в Android Market вывели на две программы.

My Archives

и SMS to Google Docs Archiver

Обе программы имеют минималистичный интерфейс и предельно схожий функционал.

SMS to Google Docs Archiver мне не понравился разделением смс на входящие и исходящие (хотя для кого-то это возможно и плюс), а так же запросом пароля от почты.

MyArchives же для доступа к документам и авторизации использует Android AccountManager, а в качестве приятного бонуса, по тому же принципу что смс, сохраняет ещё и историю звонков.
Имеется недостаток, MMS не выгружаются, но при этом удаляются. То есть мы их теряем. Но у меня их мало и все бесполезные, потому не жалко.
Если вам ММС необходимы, то либо делайте предварительный бэкап другой программой, либо удаляйте смс вручную.

Как в Git игнорировать изменение прав у файлов

Работая в среде Cygwin или MSysGit, часто бывает так что права файлов изменяются, либо внешней средой, либо внутренними процессами.
У меня наиболее часто меняется признак исполнимости. И, к сожалению, пока отсутствует время чтобы разобраться в причинах.

Загадочным, для меня, образом некоторым файлам добавляется +x, некоторым -x. И Git уже начинает считает эти файлы изменёнными, которые обязательно надо закоммитить.
Т.к. происходит такое довольно часто, то это вызывает раздражение и пустую трату времени на починку с помощью chmod и/или git reset --hard.

Так, вот, если в вашем проекте не используются системные права, то можно заставить git игнорировать изменение прав у файлов.

Отключением/включением проверки управляет ключ filemode из секции core.
Его значение необходимо установить в false.

Либо прямым редактированием .gitconfig:

[core]
        filemode = false

Либо командой:

$ git config core.filemode false

Приятной разработки!

Детерминанты - Тайна Cognos Framework Manager раскрыта

Перевод-пересказ статьи за авторством RALPH BAKER .

Детерминанты играют ключевую роль в общей производительности и целостности модели. Но, также являются для множества разработчиков одним из самых сбивающих с толку аспектов моделирования. Эта статья постарается положить конец путанице.

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

Ситуация

Например, имеется размерность времени, с гранулярностью до дня. Если все факты присоединяются к самому детальному уровню Day, тогда детерминанты не нужны. Но, как показывает практика, идеал бывает редко достижим. По множеству разных причин, факты в таблицах частенько агрегированы или хранят данные на разных уровня гранулированности.

Западня

Неприятности всплывают вместе с желанием впихнуть невпихуемое AKA присоединиться к размерности времени не по самому нижнему уровню. Рассмотрим таблицу фактов с месячными прогнозами (monthly forecast fact table); с детализацией "одна строка - один месяц". Связь через month_id будет каждый раз, в зависимости от месяца, возвращать от 28 до 31 записи, и таким образом, портить расчёты и настроение. Детерминанты решают эту проблему.

Запрос SQL

Часто, при моделировании, полезно думать о том, какой код SQL хотелось бы получить на выходе. Без детерминантов день рожденья на праздник непохож, и неправильный SQL выглядит примерно так:
SELECT
F.FORCAST_VALUE,
D.MONTH_ID,
D.MONTH_NAME
FROM SALES_FORECAST F INNER JOIN DATE_DIM D ON
F.MONTH_ID = D.MONTH_ID
Этот код, на каждую запись из прогноза, получит примерно в 30 раз больше записей, чем нужно. Математические функции, вроде Sum и Count, вернут неверный результат. Правильный же запрос, должен сначала вытащить все уникальные месяцы, каждого по одной штуке, и ТОЛЬКО ПОСЛЕ ЭТОГО присоединить факт:
SELECT
F.FORCAST_VALUE,
D1.MONTH_ID,
D1.MONTH_NAME
FROM SALES_FORECAST F INNER JOIN
( SELECT DISTINCT
D.MONTH_ID,
D.MONTH_NAME
FROM DATE_DIM D ) AS D1
ON F.MONTH_ID = D1.MONTH_ID
Как показано выше, трюк заключается в понимании какие колонки в размерности относятся к month_id, и потому уникальны в пределах ключа. Как раз в этом и заключается работа детерминантов.

Разоблачение тайны Framework Manager

Следуя лучшим практикам Cognos, детерминанты необходимо указывать в слое модели, где происходит связывание таблиц.
Ниже приведена размерность времени с 4 уровнями: Year, Quarter, Month и day.

Это означает, что, в зависимости от гранулированности таблиц фактов, представленных в модели, в тематическом запросе можно определить до 4-х детерминантов. Первые три уровня: Year, Quarter, Month должны быть группирующими, т.к. не описывают уникальную строку в таблице; и установка флага "group-by" объясняет Cognos'у, что данные по этому уровню необходимо "схлопнуть" (оставить только одно значение). Другими словами, здесь описываются правила для формирования секции "group by" в запросе SQL (такого как Год или Месяц). Уровень Day - это конечный (Leaf) уровень детализации. С целью однозначного определения любых строк внутри размерности, необходимо установить флаг “Uniquely Identified”. Детерминантов "group by" может быть множество, но детерминант по уникальному ключу, как правило, только один единственный. Детерминант "uniquely identified" по определению содержит все неключевые столбцы как атрибуты, и автоматически создаётся во время импорта таблицы, если получается его обнаружить (т.е. в таблице БД имеется первичный ключ или индексы).
Секция Key содержит колонки, которые однозначно определяют уровень. В идеале, это одна колонка, но иногда требуется больше; например, если Год и Месяц (1-12) находятся в отдельных колонках. Итак, ключ - это любые колонки, которые нужны чтобы однозначно обозначить уровень.
Исходя из размышлений выше, настройки будут выглядеть следующим образом:

Секция Attributes описывает все остальные колонки, которые относятся к уровню. Например на уровне month_id, такими являются: название месяца, дата начала месяца, количество дней в месяце (month name, month starting date, number of days). И, очевидно, что здесь отсутствуют элементы с более низкого уровня, такие как Дата или День недели (date, day-of-week).
Вообще говоря, порядок расположения детерминантов не соотносится с уровнями измерения. Однако, для понимания как строится запрос SQL, очень важно знать, что поиск колонок ведётся сверху-вниз. Если в отчёте используется Год, Квартал и Месяц, то группировка будет сделана по колонкам Year-key, Quarter-key и Month-key. Но если для отчёта нужны только Год и Месяц (без Квартала), то в секции "group by" ключ Quarter-key будет пропущен.

Сколько уровней требуется?

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

Заключение

Следуя этим простым правилам, Cognos создаст следующий запрос SQL. Выделенный кусок кода создан на основе настроек детерминантов. Обратите внимание, каким образом "схлапывается" Month_ID; для обеспечения уникальности значения уровня используется функция min. Cognos-параноик и недостотачно доверяет чистоте входящих данных, чтобы делать просто SELECT DISTINCT. Второе выражение 'group by' это обычное агрегирование, необходимое для отчёта. Так как связь теперь происходит корректно (каждый факт соединён только с одной записью размерности), в отчёт попадают правильные цифры.

Небольшой FAQ по поручительству и ипотеке Сбербанка России

Внимание!
Я не являюсь представителем банка, ответы на вопросы не являются официальными ответами банка и не являются истиной в последней инстанции.
Я не несу ответственности за любые убытки, которые вы можете понести на основе материала ниже.

Эти вопросы возникали у меня постепенно, и мне пришлось тратить время чтобы дозвониться до отделения, чтобы их выяснить.
Наверняка эти вопросы задают сотрудникам банка не один раз.
Так не проще было вывесить их где-нибудь вместе с ответами на видном месте и не тратить ни время клиентов, ни время сотрудников?
Кстати, по интонации последних, особенно чувствовалось, что эти вопросы они считают идиотскими, а людей, которые их задают, идиотами.

1. Как статус поручительства влияет на жизнь?
2. Что если поручителей больше одного?
3. Что если поручитель сам захочет взять кредит?
4. Когда снимается статус поручительства?
5. Когда требуется поручительство?
6. Могут ли пенсионеры быть поручителями?
7. Могут ли в качестве поручителя выступать индивидуальные предприниматели (ИП)?
8. Что если застройщик предлагает в качестве бонуса нежилое помещение?
9. Имеется одобрение на ипотеку приобретение квартиры на вторичном рынке недвижимости. Возможно ли, в таком случае, приобрести квартиру в новостройке?

----------------------------------------------------------------------------

1. Как статус поручительства влияет на жизнь?

Ответ: Пока заёмщик платит, то никак. Но если заёмщик платить перестаёт, то поручитель отвечает перед банком в полном объёме. Так же есть ограничения, если поручитель сам захочет взять кредит (см. ниже).

---------------------

2. Что если поручителей больше одного?

Ответ: Оба поручителя "делят" обязательства по долгу на пополам.
Смотрите пример в пункте 3.

---------------------

3. Что если поручитель сам захочет взять кредит?

Ответ: Максимальная сумма кредита, которая рассчитывается из дохода, будет меньше, т.к. из дохода поручителя отнимается сумма его обязательств по поручительству, как если бы он сам платил эту сумму.
К примеру, заёмщик платит 20000 в месяц, доход поручителя 50000р.
Догда максимальная сумма будет рассчитываться из дохода 30 т.р (50 - 20).
Если поручителей два, то рассматриваемый поручитель предъявяляет доход как 40т.р (50 - 20/2).
Точные рассчёты до копееек посчитают в отделении банка, но идея такая.

---------------------

4. Когда снимается статус поручительства?

Ответ: Как правило, когда квартира переходит в собственность и появляется возможность оформить страховку и залог.
Если поручителей больше одного, то бывает, что выводят не всех.

---------------------

5. Когда требуется поручительство?

Ответ: Всё зависит от того как налажены у банка связи с застройщиком, насколько банк ему доверяет.
В общем случае, действует такое правило, если дом готов меньше чем на 70%, то поручители требуются, если больше, то нет.
Есть небольшой, но каверзный нюанс: если одобрение было получено в одном отделении, а стройка аккредитована в другом, то есть риск, что понадобиться подавать документы заново в то отделение, которое аккредитовало стройку.
Например, я подавал документы в Царицынском отделении и мне было отказано в приобретении квартир в новостройках Подольска, т.к. все стройки были аккредитованы только Подольским отделением банка и с Царицынским они "не дружат".
Уж не знаю почему, но, опять же, это чувствовалось по интонации, когда я в одном отделении задавал вопросы про другое.
Вообще, за годы общения с банком, у меня сложилось впечатление что это не единая монолитная структура, а множество мелких феодальных анклавов, работающих по франшизе, примерно как Макдональдс.

---------------------

6. Могут ли пенсионеры быть поручителями?

Ответ: могут, если пенсия уже оформлена и возраст поручителя до 75 лет (для мужчин).
Для женщин как-то не подумал спросить, поэтому, к сожалению, не могу сказать.
Как только уточню этот вопрос, то обновлю здесь.

---------------------

7. Могут ли в качестве поручителя выступать индивидуальные предприниматели (ИП)?

Ответ: могут, если занимаются своим бизнесом больше года и подавали в этом году налоговую декларацию. Но лучше, если деклараций подавались регулярно без пропусков на протяжении всей деятельности.

---------------------

8. Что если застройщик предлагает в качестве бонуса нежилое помещение?

Ответ: Банк, как правило, кредитует только жилую недвижимость. На нежилое помещение, скорее всего, потребуется дополнительная сумма наличными.
Впрочем застройщики часто предоставляют рассрочки, так что есть возможность подкопить и не занимать у друзей.
Наличие нежилого помещения следует отразить в письме бронирования квартиры банку от застройщика.


---------------------

9. Имеется одобрение на ипотеку приобретение квартиры на вторичном рынке недвижимости. Возможно ли, в таком случае, приобрести квартиру в новостройке? И, наоборот.

Ответ: Да, это возможно. Необходимо написать заявление в свободной форме. После этого, ваше дело будет рассматриваться в кредитной комиссии несколько дней. С большой вероятностью, решение будет положительным.

Регистрация в Apple developer Program с помощью виртуальной карты

При регистрации в Apple developer Program на каком-то шаге нам сообщают: "извините, Вы не из тех стран, жителям которых мы не желаем геморроя и потому разрешаем платить карточкой через онлайн".

Отсюда, возникают пара проблем.

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

Вторая проблема, в этой форме в открытом виде необходимо передать реквизиты карточки, включая номер, дату истечения и код CVV.
Заходи кто хочешь! Бери сколько унесёшь! Я сегодня добрый, э-э-х гуляй, душа праздника просит...

Итак, что я сделал.
С некоторых пор, Яндекс, совместно с Интеркоммерц банком предлагают услугу "Виртуальная карта MasterCard Prepaid".
Через Евросеть, т.к. у них без процентов, пополняем Яндекс кошелёк на 99 долларов + небольшой запас, т.к. существует комиссия за конверсию из рублей в баксы и плюс 1.99 от номинала.

Идём на страницу покупки карты. Если вы залогинены, то увидите следующую картинку.

Соглашаемся с условиями и нажимаем "Купить карту".
Опция "уведомление по смс", в данном случае, нужна только собственного для успокоения, чтобы знать когда с карты снимут деньги. Никаких данных для подтверждения транзакции не приходило.

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

Закончили с реквизитами карты?

Не забудьте поставить свою роспись.

У меня сканера не оказалось, поэтому сфотографировал заполненную форму на фотоаппарат.
Сконвертировал в PDF.

И отправил через сервис бесплатных факсов GotFreeFax.com.

Примерно через неделю пришло уведомление, мол всё хорошо, но где деньги чувак?
Типа, твоё желание быть в нашей команде мы видим, а денег нет. Одного лишь желания мало.

На этот раз я отправил два факса через GotFreeFax.com и два через FaxZero.com.
Это были выходные.
Но факсовая спам-атака сработала. Через пару дней в мобиле появилась смс, что карту обчистили на 99 баксов.
А ещё через 5 часов пришло письмо: "Дорогой ты наш, сэр (не такой дорогой как разработчики под большой Мак, платящие 200 баксов за год, но уж какой есть), спасибо и велком в наш чудный дивный мир".

Как в Git вывести файл из под версионного контроля

Что делать, если вы когда-то взяли файл под версионный контроль, а теперь поняли что он не нужен?
И что делать, если файл, который находится под контролем вы меняете локально, и эти изменения нельзя коммитить?
В обоих случаях .gitignore не работает. А действовать надо так:

$ git rm --cached <file>

Данная команда выведет файл из под версионного контроля при следующем коммите, но оставит его живым в рабочем каталоге.