Бизнес не любит:

1. 1С-Франчайзи, программистов 1С вообще, и почти все, что те делают;
2. веб-программистов и компании, создающие и продвигающие сайты, и все продукты их работы;
3. системы менеджмента качества и людей, которые занимаются их внедрением;
4. бухгалтеров и бух.учет;
5. экономистов со всеми их гигантскими экселевскими портянками;
6. внутренние проекты развития, на которые без слез уже смотреть невозможно;
7. Scrum и все эти доски, на которых неделями висят одни и те же стикеры;
8. ТОС, после внедрения которого дефицитов и неликвидов становится еще больше;
9. Контроллинг, который дает цифры позже, чем бух.учет;
10. KPI, адекватность которого приходится доказывать самому себе каждый раз, когда приносят эти цифры;
11. Системы мотивации, которые, как ни крути, «оклад+премия», хоть и названы модными словами, типа «грейд».

Продолжать можно до бесконечности. Никогда не задумывались, почему бизнес всего этого не любит? Или вообще не замечали, что бизнес этого не любит?

При этом, как ни странно, бизнес любит:

1. повышение прибыльности бизнеса за счет автоматизации;
2. увеличение количества лидов и рост оборота за счет правильного продвижения;
3. повышение качества процессов производства и бизнес-процессов;

Введение

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

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

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

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

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

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

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

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

Поехали.

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

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

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


Startup Graveyard

Учимся на горьком, но полезном опыте предшественников. Strartup Graveyard — это каталог стартапов, которые потерпели неудачу и вынуждены были выйти из игры. Цель проекта, как уверяют авторы, вовсе не в том, чтобы клеймить людей за ошибки — напротив, объективный безоценочный анализ факторов, которые привели ту или иную компанию к печальному исходу, позволит «снять стигму с неудачи» и выстроить более открытое, вдумчивое сообщество. История болезни излагается в лаконичной, ясной форме: название, ниша, годы жизни, инвесторы и бюджет, конкуренты, основные причины краха. Посетителям также предлагается внести свою лепту — произвести вскрытие такого рода над известным им проектом (возможно, даже своим собственным) и отправить результаты администрации.

Некоторое время назад я менял работу, и занимался активным поиском работы менеджера — руководителя проектов в области IT. И я обратил внимание, на довольно частое требование знание методологии PMI, PMBok.

И вот на моей текущей работе есть довольно много менеджеров проекта, скажем так начального и среднего уровня. У руководства компании есть много претензий к тому, как проекты выполняются. Что же делать? Первая мысль — отправить всех учиться управлению проектами и лучше всего дать методологию PMI.

Исследование рынка

• Google’s Keywords Tools
• Google Trends
• App Annie – Анализ приложения, Аналитика, Исследование рынка
• Distimo – Анализ приложения, Загрузка оценок и исследования
• Xyologic – Новый подход к поиску мобильных приложений
• Apptrace – Исследование App Store
• AppMonsta – Данные о рынка приложений
• Vision Mobile – Экосистема аналитики фирмы
• MetricsCat –Анализ данных приложения

Маркетеривание/Прототипирование

• POP (Прототипирование на бумаге) – Прототипирование мобильных приложений
• Mockabilly – Приложение для создание макетов для iPhone
• Interface – Продвинутое макетирование и прототипирование под iOS
• Blueprint – Макетирование приложений для iPad и iPhone
• Proptotypes – Меняет статический дизайн в кликабельный прототип для iPhone
• FieldTest – Создание мобильного интерактивного прототипа
• Keynotopia – Keynotopia превращает Keynote и PowerPoint в лучшие инструменты быстрого прототипирования для создания макетов приложений
• Justinmind – Интерактивные каркасы для создания веб- и мобильных приложений
• Fluid UI – Прототипирование под iOS, Android и Windows Приложений
• UI Stencils – Трафареты, эскизы и аксессуары для дизайна пользовательского интерфейса
• App Cooker – Продвинутый генератор макетов для мобильных приложений под iOS
• Proto.io – Мобильное прототипирование
• UXPin – Средства проектирования UX
• AppGyver’s Prototyper – Меняет каркасы в прототипы интерактивных мобильных приложений
• App Mockup Tools – Создание прототипов для iPhone приложений
• WireKit – Комплект каркасов для iPhone приложений
• DevRocket – Панель плагина Photoshop для iOS — разработчиков
• Flinto – Быстрое создание прототипов для iOS
• App Icon Template – Шаблоны иконок для iOS 7 и Android приложений
• PortKit – UX Metaphor Эквивалент для iOS и Android
• iOS 7 Wireframe Kit – «Набор для Иллюстратора, чтобы сделать ваш вайфрейминг днем на пляже»
• SketchMirror –Превью дизайна мобильных приложений со своего девайса
• Invision – Веб и Мобильное прототипирование, а также инструмент для UI прототипирования
• Framer –Инструмент для прототипирования анимаций
• Marvel – Бесплатный инструмент для прототипирования
• Sketch – Профессиональный цифровой дизайн для Mac

На одной улице в Бердичеве жили трое портных. У первого была вывеска: “Лучший портной в городе”, у второго — “Лучший портной в мире”, а третий написал: “Лучший портной на этой улице”.

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

Вы никогда, НИКОГДА не станете богатым от экономии на покупках в супермаркете!

Сотни миллионов людей в мире экономят как на покупках, так и на самих супермаркетах, не говоря уже о миллионах голодных, “экономящих” на еде вообще. Можно предположить, что достаточно большая часть экономящих людей попадается на удочку относительно больших чисел, получаемых умножением грошей на 20-30-40 лет… без какого-либо положительного финансового эффекта. Причина элементарна: экономический план на десятки лет — это оксюморон. Такой план не учитывает множество факторов, влияние которых весьма значительно и на более короткие сроки, поэтому он может называться мечтой, фантазией, как угодно еще, только не финансовым планом. Кризисы, биржевые скачки, инфляция, изменения в жизни, в работе, в уровне доходов, политической обстановке… да одна только кратковременная флюктуация в курсе валют может мгновенно уничтожить нажитое непосильным трудом (как и наоборот, кстати). Вы не разбогатеете за 20 лет, отказывая себе в шоколадках, или не тратя деньги на сигареты, или “собирая бутылки”. Вернее, не так. Ваш шанс разбогатеть за NN лет совершенно не зависит от ваших сегодняшних действий и еще меньше зависит от мелочей. А все потому, что

В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures» Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.

Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.

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

В 1996 году аспиранты Стэнфордского университета Сергей Брин и Ларри Пейдж начали разработку компьютерной программы, которая впоследствии станет известна миру как поисковая система Google.

Сегодня Google (Alphabet) — крупнейшая корпорация с рыночной капитализацией $450 млрд. Сергей Брин сосредоточил усилия на перспективных научно-исследовательском подразделении GoogleX, которое занимается революционными разработками вроде беспилотных автомобилей.

В одном из интервью в 2000 году Сергей Брин рассказал, какие книги вдохновили его посвятить карьеру технологиям, где смешаны наука и творчество.

Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.

Здравствуйте, дорогие читатели!

Не так давно мы занялись проработкой книги "Writing High-Performance .NET code", которая до сих пор не переведена на русский язык, хотя ей и скоро год.



Нас, конечно, не удивило, что такую книгу уже растаскивают на цитаты, однако выяснилось, что уважаемый автор Бен Уотсон даже выложил на сайте «Codeproject» целую статью, написанную по мотивам одной из глав. К сожалению, объем этого материала слишком велик для хабропубликации, однако мы решили все-таки перевести первую часть статьи, чтобы вы могли оценить материал книги. Приглашаем к прочтению и к участию в опросе. Кроме того, если все-таки целесообразно перевести и вторую часть — пишите в комментариях, постараемся учесть ваши пожелания.

Есть один курс, который я бы добавил в программу обучения по всякой инженерной специальности, и он не о компиляторах или сложности алгоритмов. Это “Введение в реальность индустрии”, ибо об этом не говорят и это приводит к никому не нужным обломам. Эта статья претендует стать README.txt для молодого инженера в деле построения карьеры. Ее цель — сделать вас счастливее, заполнив пробелы в образовании относительно того, как работает реальный мир. Я не призываю следовать написанному как подробному руководству, но я надеюсь, что эта информация окажется для вас более ценной, чем то ничто, что вам рассказали об этом в университете.

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

Неважно, запускаете ли вы новый продукт, продаете что-либо на eBay или же заключаете сделку о продаже дома – вы научитесь устанавливать цены, которые максимизируют вашу прибыль.

Захотелось поделиться с сообществом собственными наблюдениями на тему карьерного роста технаря.

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

Начнем сначала: вы свежий выпускник тех. вуза. Вам 22-23 года, вся жизнь впереди и она прекрасна. В этом прекрасном будущем есть, скорее всего, есть жена-модель, дом – полная чаша, несколько машин, и первый миллион к 30 годам.

Карьера представляется немного смутно, но в целом, понятно: начинаем активно и качественно работать, нас, несомненно, замечают и продвигают. Множество фильмов и книг именно так нам и обещают: много и хорошо работай –> и всё будет хорошо.

Вы устраиваетесь на работу, ваше звание — инженер или разработчик. У вас появляются коллеги. Почти все они старше вас. И тут вы, возможно, заметите, что на таком же уровне, как и вы, есть очень пожилые люди. Прямо 30-40 летние мужики, может даже 50ти летние “стариканы”. И многие из них тоже закончили похожие вузы, и многие совсем не дураки, но как-то не сложилось с карьерным ростом…

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

Камень преткновения — GC

Все managed языки такие как Java или C# имеют один существенный недостаток — безусловное автоматическое управление паматью. Казалось бы, именно это и является преимуществом managed языков. Помните, как мы барахтались с dandling-указателями, не понимая, куда утекают драгоценные 10KB в час, заставляя рестартать наш любимый сервер раз в сутки? Конечно, Java и C# (и иже с ними) на первый взгляд разруливают ситуацию в 99% случаев.

Так-то оно так, только вот есть одна проблемка: как быть с большим кол-вом объектов, ведь в том же .Net никакой магии нет. CLR должен сканировать огромный set объектов и их взаимных ссылок. Это проблема частично решается путём введения поколений. Исходя из того, что большинство объектов живёт недолго, мы высвобождаем их быстрее и поэтому не надо каждый раз ходить по всем объектам хипа.

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

Однако на практике это сделать не удаётся. Как только мы добавляем первые 10 миллионов объектов и они “устаревают” из первого поколения во второе, то очередной полный GC-scan “завешивает” процесс на 8-12 секунд, причём эта пауза неизбежна, т.е. мы уже находимся в режиме background server GC и это только время “stop-the-world”. Это приводит к тому, что серверная апликуха просто “умирает” на 10 секунд. Более того, предсказать момент “клинической смерти” практически невозможно.
Что же делать? Не хранить много объектов долго?

Зачем

Но мне НУЖНО хранить очень много объектов долго в конкретной задаче. Вот например, я храню network из 200 миллионов улиц и их взаимосвязей. После загрузки из flat файла моё приложение должно просчитать коэффициенты вероятностей. Это занимает время. Поэтому я это делаю сразу по мере загрузки данных с диска в память. После этого мне нужно иметь object-graph, который уже прекалькулирован и готов “к труду и обороне”. Короче, мне нужно хранить резидентно около 48GB данных в течении нескольких недель при этом отвечаю на сотни запросов в секунду.

Вот другая задача. Кэширование социальных данных, которых скапливаются сотни миллионов за 2-3 недели, а обслуживать необходимо десятки тысяч read-запросов в секунду.

В данной статье я хочу поделиться с вами некоторыми экспериментами по созданию анимированных кнопок при помощи CSS3. Идея заключается в создании анимированных ссылок с разными стилями, hover-эффектами и пр.

В данных примерах используются иконки с webiconset.com, а также шрифт от Just Be Nice.

Мы рассмотрим каждый пример и разберем как выглядит их HTML-структура и стили для разных состояний кнопок.

Обратите внимание, что анимация/переходы будут работать только в браузерах, которые поддерживают эти CSS3-свойства.

Чтобы не захламлять код в уроке я не буду использовать префиксы для различных браузеров. Их вы сможете увидеть в архиве с примерами.

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



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

Прежде, чем начать работать с ListFragment, давайте немного изучим, что же находится внутри?

Резюме

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