В заметке я постараюсь начать описание нескольких интересных дополнительных возможностей этой замечательной читалки,. Речь пойдет о вариантах Kindle 3g и Kindle Wi-fi третьего поколения и некоторых штуках, не описаных в мануалах. Хотел бы заметить, что информацию о Киндле найти относительно не сложно, однако собрать все в одной заметке на русском, думаю, неплохая идея.

• Итак, почему IELTS?
• Почему я выбрал имменно IELTS-Moscow?
• Listening
• Почему невозможно списать/сговориться с экзаменаторами/сжухлить?
• Какая разница между General и Academic модулями IELTS?
• Reading
• Что спрашивают и сколько времени?
• Сложные ли вопросы?
• Writing
• Salmon — это лосось, а не осётр (я их по-русски путаю)
• Сколько баллов нужно получить и для чего?
• Почему результаты будут только через 13 дней? (24 февраля 2010)
• Speaking
• Стоит ли шутить с экзаменатором?
• Что делать, если попались темы, о которых вам НЕЧЕГО сказать?
• Правда ли, что экзаменатор — как трамвай?
• Что делать, если во время IELTS теста ты спокоен?
• Та самая эпическая битва подкастера и радиоведущего
• Голосовые фидбеки сюда! (без паники, заодно тестирую soundcloud)

P.S. Все вышедшие выпуски подкаста можно скчать разом (торрент). Там папки, по 10 выпусков (кому не нужны сразу 154 файла или не хочется качать все сразу). Многие эпизоды представлены и на сайте подкаста: rosnovsky.ru

Наверняка многие из вас попадали в ситуацию, когда в американском интернет-магазине есть интересующая вас вещичка по заманчивой цене, но доставку магазин осуществляет только в пределах США. Например, в крупнейшем интернет-магазине Amazon жители из стран СНГ могут заказывать лишь книги и фильмы, и то не все. Конечно же, можно компенсировать данный недостаток с помощью ebay, но где еще у вас может быть шанс купить iPod Touch 32 GB 3rd Gen за $269.99, а Nokia N900 за $559.99? А может, грешным делом заказать Nexus One? Падение доллара и ценовая политика производителей сделала покупки в США достаточно заманчивым делом.

Данной статьей я постараюсь продолжить обзор стран, начатый в Денег нет, погода дрянь и правительство ввело новые поборы. Что делать?. Я не хочу обсуждать почему, зачем, что меня двигало к переезду (кому-то весело и комфортно только в Нью-Йорке/Лондоне, а кто-то весьма доволен и в деревне), а постараюсь просто привести некоторую информацию. Здесь на сайте довольно много людей из Австралии, надеюсь где-то меня поправят, что-то добавят. С удовольствием отвечу на все вопросы в комментариях.

Эта статья – часть серии «Как написать резюме». Чтобы начать серию сначала, прочитайте введение.

За свою жизнь, я использовал несколько плохих слов. Даю %^й на отсечение, что вы тоже делали это. Но, когда неправильные слова появляются у вас в резюме – это делает его отстойным.

Для чего выдумывать все эти паттерны проектирования, принципы и методики? Разве не было бы проще обойтись без всего этого, а просто научить разработчиков хорошему дизайну? Или почему бы не формализовать этот процесс и ввести четкие количественные метрики, которые бы говорили, что одно решение однозначно лучше другого?

«Правильный дизайн» — это святой Грааль молодых разработчиков и молодых менеджеров. И те, и другие мечтают найти ответ на главный вопрос жизни, вселенной и всего такого разработки ПО – как добиться качественного дизайна, в сжатые сроки и с минимумом усилий.

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

Вот уже полтора года я зарабатываю фрилансом на бирже oDesk. За это время у меня накопилось много материалов по данной теме. В данном топике я собрал все в одну статью и адаптировал для аудитории хабра.

Great Appeal или девушка на миллион

Итак, в прошлой статье мы закончили на том, что разобрались с тем, как получить «показы» нашего приложения в AppStore.

Иногда ошибочно считается, что запуск – это самое сложное. Это, мягко скажем, не так. Настоящая работа начинается после запуска.

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

В жизни многих обитателей софтверной индустрии иногда настаёт момент, когда им приходится нарисовать план проекта. Люди, что-то слышавшие об управлении проектами, читавшие книжки на эту тему (особенно книжки, не описывающие конкретную индустрию), а также учившиеся управлению проектами где-либо (в ВУЗе, на курсах и т.п.) чаще всего автоматически выбирают для создания этого плана Microsoft Project. Иногда использование MS Project навязывается руководством, клиентом, процессными стандартами в компании и т.п.

Для софтверных проектов выбор MS Project обычно крайне неудачен и ниже мы объясним почему, но сначала напомним несколько простых фактов о том, как устроены софтверные проекты, особенно в контексте заказной разработки.

Моя статья будет представлять собой больше набор историй из жизни и некоторые выводы из них. Основная проблема, которая меня сейчас волнует: как сделать так, чтобы довольны были и заказчики, и разработчики, и прибыль была и карма цела. Конкретного окончательного рецепта у меня нет, есть несколько отрицательных примеров и намеченные цели, которыми хочется поделиться.
Я занимаюсь разработкой с 2003 года (в основном web-приложения), до этого 4 года преподавала в ОмГУ основы программирования для 1-го курса математического факультета. На данный момент у меня пошел 3-й год в роли совладельца собственной небольшой аутсорсинговой компании. Рассказывать буду исключительно о своем опыте по двум причинам: я успела побывать в трех различных типах компаний, которые могу сравнить, и считаю, что пересказ чьего-то опыта не дает полной картины.

Несмотря на то, что распределенные системы контроля версий (Git, Mercurial, Bazaar) набирают все большую популярность, старый добрый Subversion по-прежнему широко используется. В данной статье я рассмотрю плюсы и минусы использования на практике внешних зависимостей (svn:externals) в SVN репозиториях.

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

Сразу скажу, что получение денег на пластиковую карту без уплаты налогов может вылиться в серьезные проблемы (про ответственность написано в конце топика). Объяснения, что деньги «от бабушки внучку на мороженное» при суммах больше 10К$ в год уже не прокатывают, особенно если в реквизитах «бабушки» будет стоять что-то вроде «GMBH Star Development» Вероятность того, что возьмут за задницу достаточно высокая и поэтому лучше не рисковать и делать все по Закону, тем более, что ничего сложного в этом нет

В соседней теме попросили рассказать о нюансах работы с зарубежными клиентами для ИП/ООО. Для физических лиц работа с нерезидентами ничем не отличается работы с резидентами.
Это скорее даже не статья, а заметка/памятка, но возможно кому-нибудь будет хоть немного полезна.

Регистрация счета

Предположим что вы закончили регистрацию ИП/ООО и открыли рублёвый расчетный счет.
Для того чтобы работать с валютой нужно открыть еще один расчетный счет — валютный. Это просто.
При открытии валютного счета вам создадут дополнительно технический транзитный счет. Его реквизиты и нужно сообщать заказчику.

Здесь мы встречаем потенциальный косяк номер раз: как и в случае с рублевым счетом нужно уведомить налоговую в недельный срок (штраф — 5000 рублей [1]). Затем не забыть уведомить и своё отделение ПФР в тот же срок, иначе опять же штраф, но уже меньше — 2000. Если вы зарегистрированы в ФСС, то нужно не забыть так же и их, всё аналогично случаю с ПФР. [2]

ООО нужно уведомить ПФР и ФСС только если есть работники. ИП — обязательно ПФР, но если есть или были работники, то и ФСС.

Некоторые госслужбы «не шарят» и пытаются оштрафовать если не уведомили о транзитном счете. Это противозаконно и легко решает даже в досудебном порядке, не говоря уже о суде. Заявлять нужно только об обычном счете, о транзитном — не нужно.

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

В посте речь пойдет о моем опыте встраивания XML-RPC интерфейса в утилиту, написанную на C. Интерфейс должен предоставлять доступ к статитстике и результатам работы утилиты. Одно из требований к интерфейсу — поддержка ответов в формате gzip, в целях экономии трафика. Мне очень хотелось обойтись малой кровью и вот что из этого получилось.

Когда мне предложили данную тему для написания своих мыслей в виде статьи, я долго думал, о чем же написать, потому что, по сути, вся данная статья укладывается в одно предложение, которое является прямым ответом на данный вопрос — Все документы должны быть прописаны и никаких моментов не должно быть в уме. Почему именно так? Рассмотрим по пунктам:

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

Anki — это программа для запоминания иностранных слов. Список её преимуществ перед аналогами впечатляет! Судите сами:

• Широкие возможности по настройке вида карточек
• Поддержка мультимедиа
• Большое количество плагинов
• Настройка алгоритма обучения
• Подробная статистика
• Поддержка большинства современных платформ (Linux, Windows, Mac, iPhone, Android, список можно продолжить!)
• Синхронизация данных

И всё бы хорошо, да вот только благодаря таким обширным возможностям, в Anki может быть не так просто разобраться. Надеюсь, мой скринкаст вам в этом поможет.



Официальный сайт — ichi2.net/anki
Программу можно найти в Центре приложений Ubuntu.

Тема образования и OpenSource последнее время очень активно освещается в средствах масс-медиа.
В большинство случаев это очередные сборки Линуксов с малым количеством образовательных программ «из коробки»
Например:
http://www.edubuntu.org/
http://en.opensuse.org/openSUSE:Education-Li-f-e
http://www.altlinux.ru/solutions/state/school/
http://edumandriva.ru/

Но ведь OpenSource это не только GNU/Linux!
Почему не подумают о тех кто приобрел MS Windows официально (по собственному желанию или принудительно в придачу при покупке нового компьютера)?

Одним из решений предлагается Windows OpenPack (Education)…

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

Я не могу безболезненно сидеть за столом дольше часа подряд, и я не могу работать больше, чем стандартный восьмичасовой день. Проблема в том, что последние 15 лет моя стратегия работы заключалась в том, чтобы поймать «поток» и после этого кодить очень долго без перерывов. Эта стратегия очень популярна у кодеров, любящих запираться на сутки, надевать наушники и отключаться от внешнего мира — и именно поэтому они так болезненно реагируют, когда их отвлекают. Программирование требует концентрации, а концентрация работает по принципу клапанного механизма — на разогрев и запуск требуется время, поэтому уже запущенный механизм лучше не останавливать.

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

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

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

Большинство провальных проектов обладают одной закономерностью. Они абсолютно лишены структуры. Я называю архитектуру таких систем «пластилиновой».