Введение

Последние месяцы на Хабре мне часто попадаются обсуждения налогов в США. Как правило, это происходит в топиках, где обсуждение по какой-то причине скатилось к вечным темам «у нас все плохо — у них хорошо», «у нас хорошо — у них все плохо», «пора валить отсюда», «Да в США такие налоги, что непонятно, как бедные люди вообще там выживают» и т.п.

В очередной раз наткнувшись на такое обсуждение, я спросил тут же в комментарии и даже задал соответствующий хабравопрос — народ, а может вместо того, чтобы беспорядочно спорить о налогах в США в куче разных топиков, давайте я напишу отдельный подробный пост на эту тему, и там и будем спорить? За этот комментарий и хабравопрос я получил изрядно кармы и хабрасилы, и, собственно, на этом можно было бы и остановиться ибо цель достигнута, муа-ха-ха. Однако, меня уже начинают спрашивать некоторые люди, где же обещанная статья, и судя по всему, отвертеться от написания поста мне не удастся…

Обсуждающие налоги в таких топиках делятся, как правило, на три заметные группы:

• Те, кто о налогах в США знает мало, но хотел бы узнать побольше из первых рук, а так же задать в одном месте все интересующие вопросы и получить ответы всего за 0.99$ за один ответ!
• Те, кто реально разбирается в предмете (в 90% случаев это люди, работающие и живущие в США). В обсуждениях участвуют обычно короткими репликами, так как вопрос сложный и расписывать все в деталях каждый раз лень и вообще дело неблагодарное.
  
• Те, кто о налогах в США знает из разных сомнительных источников, вроде блогпостов диванных аналитиков, но мнение имеет.
  

Для первых я и решил написать этот пост. От вторых я с благодарностью приму замечания и дополнения. Третьи могут не беспокоиться.

В первой части я напишу про налоги вообще, про федеральный налог и налог штатов и как они вычисляются и про Social Security / Medicare tax.

Во второй части (coming soon) — про годовой цикл налогообложения и различные формы — W-2, W-4, 1040NZ и прочее и прочее.

В третьей части (coming soon) — про процесс подачи Tax Return, про сайты которые помогают заполнять здоровенные формы, про применение налоговых вычетов, и, ГЛАВНОЕ о налогах в США — если есть основания, как можно получить обратно существенную часть удержанных с вас налогов. Поэтому, читая этот пост, держите в голове — большинство людей платит существенно меньшие налоги, чем те, которые я тут вычисляю для примера без учета возможных вычетов.

Поехали.

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

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

Как это работает

Не так давно я задавал вопрос в Groovy mail-list — есть ли какой-то устойчивый список вещей, которые надо избегать при написании высокогопроизводительного на Groovy. Среди прочих советов, один из главных разработчиков Groovy, Jochen «blackdrag» Theodorou указал, что в общем случае, зачастую использование конкретного типа при объявлении переменной (например, MyType var =… вместо def var = ...) может ухудшить производительсть из-за накладных расходов на проверку типов и, если нужно, их приведение.

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

Перед этим экспериментом будет полезно просмотреть следующую статью — groovy.codehaus.org/From+source+code+to+bytecode, где рассказывается про то, как по шагам исходный код на Groovy преобразуется в байткод JVM, а так же почитать какую-нибудь вводную статью в собственно байткод, например эту — www.ibm.com/developerworks/ibm/library/it-haggar_bytecode.

Не так давно мне нужно было быстро поднять маленькую виртуалку под Linux, чтобы проверить переносимость одного модуля в своем приложении, написанного на Java и вызывающего Oracle SQL Loader через java.lang.Process API.

Поскольку, как известно, Oracle SQL Loader не входит в поставку Oracle Instant Client, то для такой задачи надо или копировать руками нужные библиотеки с машины, где установлен сервер, либо ставить на этой виртуалке полный сервер Oracle.

Установка Oracle Enterprise Edition под Ubuntu это задача не на 5 минут. Полная и точная (по словам автора — я сам пробовал многочисленные похожие инструкции, все равно полностью без ошибок поставить ни разу не удавалось) инструкция находится здесь — www.excession.org.uk/blog/installing-oracle-on-ubuntu-karmic-64-bit.html. Сравните, насколько это геморройнее и сложнее, чем установка того же Oracle EE под Windows — там запустил OUI (Oracle Universal Installer) и следуешь его указанием. Короче, отличный пример протекающей абстракции в Linux среде (хотя, казалось бы, user-friendly дистрибутив) в духе Джоэля Спольски.

Но для Express (XE) версии есть все же человеческое решение.

Недавно на Хабре мелькал вопрос — так нужен ли на самом деле ORM в крупном и сложном проекте? Ведь он часто медленный, громоздкий, поддерживает только некоторое подмножество SQL, не поддерживает специфический и очень удобный синтаксис, например, Oracle (тот же connect_by для иерархических запросов) и прочее и прочее.

Высказывалось мнение, что ORM в действительности нужен только в примитивных проектах, для сокращения размера кода, а в реально большом и сложном проекте лучше обойтись без него. Я скажу за большие проекты — за мелкие пусть скажут другие :) Оговорюсь, что рассуждения и примеры строю на Java / Oracle, классическая связка.

В подмножестве экосистемы Java, относящейся в основном к JNI (без которого никуда не деться, если приходиться интегрироваться с каким-то legacy или просто редким и специфическим кодом, написанном на С или каком-то другом языке), есть такое понятие, как java.library.path. Вкратце, это в некотором роде аналог classpath, только не для Java классов и *.jar файлов, а для нативных библиотек — системное свойство, которое указывает JVM, где искать эти самые нативные библиотеки (.dll в винде или .so под юниксами).

Свойство это устанавливается один раз, перед запуском JVM, через глобальные system properties, или как ключ -Dname=value для JVM, и после этого оно становится read-only. Точнее, менять-то его можно, но никакого эффекта на работу программы это не окажет, т.к. после того как вы обновите это свойство, JVM не перечитает его и не будет использовать новое значение.

Под катом — про то, как все таки поменять это свойство в рантайме, и немного о том, как собственно работает загрузка нативных библиотек в Java.

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

Первая — JavaOne (http://www.oracle.com/ru/javaonedevelop/index.html), 12-13 апреля 2011, в Москве.
Вторая — Application Developer Days (http://addconf.ru/), 29-30 апреля 2011, в Питере.

Захотелось попробовать развить здесь одну любопытную дискуссию, которая была начала тема в комментах к будущему подкасту Радио-Т (кстати сами подкасты бывают иногда интересны), но тут же заглохла из-за отсутствия кворума.

Дискуссия о, собственно, будущем Java как языка, и как платформы.
Если вкратце — что могут сделать те, кто направляет развитие Java, чтобы удержать ее на плаву в течении долгого времени. По ссылке выше обсуждение пошло было в сторону того, почему в лабораториях Microsoft Research более или менее активно разрабатываются альтернативные языки для платформы .NET (такие, например, как F#), а вот Sun/Oracle с такой поддержкой альтернативным языкам отстают.

Некоторое время назад я описал свой опыт и свои ощущение от сдачи двух сановских сертификатов SCJP и SCBCD — habrahabr.ru/blogs/java/84405. В этом топике не будет ни слова о моем опыте сдачи SCEA — en.wikipedia.org/wiki/Sun_Certified_Enterprise_Architect — экзамена на Java-архитектора, так как я только еще собираюсь его сдавать.

Однако, если здесь есть кто-то еще, кто собирается его сдавать, или может уже сдал, предлагаю обсудить. Смысл и перспективы сдачи, ненужные понты / полезная вещь, слишком дорого и долго / терпимо, кто как готовился и как сдавал, и кому как этот сертификат пригодился (или оказался бесполезной бумажкой для ЧСВ).

Это по сути мой эксперимент для топиков такого формата. Можно ли устроить в топике обсуждение такого вида, и сделать его полезным? Если мы соберем здесь какой-то полезный опыт, я его обобщу в теле топика в назидание потомкам .

Пара ссылок для затравки, хотя все легко гуглится, в принципе.

en.wikipedia.org/wiki/Sun_Certified_Enterprise_Architect
in.sun.com/training/certification/java/scea.xml
www.ibm.com/developerworks/ru/edu/j-scea/index.html
www.whizlabs.com/scea/scea.html

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

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

Итак:

В одном из постов недавно мелькала эта мысль habrahabr.ru/blogs/arbeit/106832 — должны ли тестовые задания оплачиваться или нет.

Мое мнение, что тестовые задания НЕ должны оплачиваться (точнее, такой проблемы вообще вставать не должно), и вот по какой причине.

Под катом — мой вольный перевод (части) одной любопытной статьи Пола Грэма, описывающей принципиальную разницу между расписанием типичного менеджера и типичного «maker-a» — разработчика в частности.

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

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

Прежде всего — java.sun.com/javase/6/webnotes/6u18.htm l.

Коротко:

Саппорт для нескольких новых конфигураций — Windows 7, Red Hat Enterprise Linux 5.3, Firefox 3.6.

VisualVM версии 1.2 с новыми фичами (мне, например, понравился семлинг-профайлинг).

Java DB — добавлена Java DB 10.5.3.0.

Улучшения производительности, в т.ч. на уровне JVM (новая версия JVM — Hotspot 16 включена в релиз).

Никаких security fixes — все последние уже есть в 17-ой версии.

Прошу прощения за короткий пост, но времени мало, и решил лучше запостить такой. Все равно те, кому по настоящему интересно, пойдут читать оригинал :))