Сколько слов в английском языке? Oxford English Dictionary содержит около 500 000 словарных статей, не учитывая специфические научные слова и выражения (которых насчитывается еще порядка 500 000). А как вы думаете, какой средний словарный запас иностранного языка дает вам средняя школа за время обучения? Правильный ответ – около 2500 слов. Мало ли этого набора? Тут уже надо исходить из ваших целей. Для общения с иностранцами на деловые темы – однозначно мало. Для чтения несложных текстов в интернете – более чем достаточно. Если быть точнее:

400–500 слов – активный словарный запас для владения языком на базовом (пороговом) уровне.
800–1000 слов – активный словарный запас для того, чтобы объясниться; или пассивный словарный запас для чтения на базовом уровне.
1500–2000 слов – активный словарный запас, которого вполне хватит для того, чтобы обеспечить повседневное общение в течение всего дня: или пассивный словарный запас, достаточный для уверенного чтения.
3000–4000 слов – в общем, достаточно для практически свободного чтения газет или литературы по специальности.
Около 8000 слов – обеспечивают полноценное общение для среднего европейца. Практически не нужно знать больше слов для того, чтобы свободно общаться как устно, так и письменно, а также читать литературу любого рода.

К этим данным пришел известный шведский полиглот Эрик Гуннемарк, основатель Международной ассоциации `Amici Linguarum` (`Друзья языков`). Более того, он составил набор минимального количества слов и выражений, которые необходимо знать, для порогового уровня владения языком, назвав их Минилекс и Минифраз.

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

Программное обеспечение проникает во все щели человеческого общества. Мы узнаем погоду через интернет, а не через обычный градусник за окном. Мы едем по новому адресу с навигатором, а не ищем квадрат G7 на странице 59. Мы включаем RunKeeper, когда катаемся на велосипеде, чтобы узнать среднюю скорость и похвастаться в твиттере. Мы используем софт каждый день. Наверное, бОльшую часть жизни мы уже проводим в обнимку с любимыми гаджетами и программным обеспечением, а не с любимым человеком.

Проблема в том, что никто не знает, как на самом деле писать классный софт быстро и правильно. Waterfall благополучно скончался на рубеже веков, а новые методы разработки (agile) пока не могут решить фундаментальные проблемы.

Представляю вашему вниманию перевод статьи под названием "Better together; the practice of successful creative collaboration" от Stefan Klocek. Перевели специально для пользователей Хабрахабра с одобрением компании Cooper.

Рок-звезда и гениальный ученый обязательно являются одиночками. Именно так мы привыкли представлять себе работу творческого человека. Однако творческая работа также может процветать благодаря таким вещам, как различия, упорство, обмен идеями и сотрудничество.



Двое (или больше) творческих людей могут использовать эти добродетели, если будут хорошо играть в команде. Практика “парного дизайна”, используемая в Cooper, взрослела больше чем десять лет, и развивается вместе с ростом компании, формируя новые пары, в которых дизайнеры учатся друг у друга каждый день. Хотя не существует никакой магической формулы, но большинство самых успешных совместных работ такого плана на нашей памяти обладали на удивление схожими характеристиками.

Однажды, nickivanov нарисовал миниатюры для кучи разных флагов и выложил их в свободный доступ. А недавно, artpolikarpov собрал их в один спрайт и написал к нему удобный css, который позволяет легко отобразить любой флаг просто указанием нужного класса.

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

И был бы этот топик топиком-ссылкой, да по необъяснимым причинам не разрешает Хабр в топиках-ссылках указывать авторов, заслуживающих похвал. Так что вот они ссылки:
Описание: artpolikarpov.ru/projects/flags
Архив с флагами: artpolikarpov.ru/projects/flags/flags.zip

Достаточно не тривиально разработать хорошо спроектированный front-end веб-приложения с уровнем отклика, производительностью и фичами, которые ожидают пользователи сегодня. Легко потеряться в кипящей смеси jQuery обработчиков событий, HTML разметки и AJAX вызовов и даже относительно простой GUI быстро может стать кошмаром для сопровождения.

Один из способов добавления некоторой структуры и порядка на клиентской стороне – использование фреймворка вроде Knockout. Knockout – это свободная Javascript библиотека с открытым исходным кодом, которая помогает реализовать Model-View-View Model (MVVM) паттерн на клиенте. Она хорошо документирована и официальный веб сайт великолепная точка старта с кучей реальных примеров, которые не только демонстрируют использование встроенных фич библиотеки, но и показывают, как расширить её свои собственными фичами.

В этом посте мы рассмотрим, как Knockout может быть использован совместно с плагином отображения, каким-нибудь jQuery и ASP.NET MVC 3 backend (или модель, как вам нравится) для построения простого, но эффективного приложения для живого поиска в Twitter.

Некоторые замечания о времени

• UTC: время на нулевом меридиане называется Всемирное координированное время, Universal Coordinated Time. Несовпадение акронима было вызвано необходимостью универсальности его для всех языков.
• GMT: ранее вместо UTC использовалось среднее время по Гринвичу (Greenwich Mean Time, GMT), так как нулевой меридиан был выбран так, чтобы проходить через Гринвичскую королевскую обсерваторию.
• Прочие часовые пояса могут быть записаны как смещение от UTC. Например, Австралийское восточное стандартное время (EST) записывается как UTC+1000, то есть время 10:00 по UTC есть 20:00 по EST того же дня.

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

Наткнулся на Stackoverflow.com на интересный топик с вопросом о новом в программистском жаргоне. Предлагаю здесь подборку наиболее интересных выражений.

Египетские операторные скобки

if (a == b) {<br>  printf("hello");<br>}<br><br>

Быстро! Ответьте на следующий вопрос:

Как вы оцениваете свой уровень как программиста (ниже среднего, средний, выше среднего)?

Согласно психологическим опросам среди разных групп, около 90% программистов отвечают «Выше среднего».

Очевидно, это не может быть правдой.

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

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

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

Следы от пуль

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

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

Логично заключить, что нужно добавить брони в тех местах, где больше всего следов. Но это неверно.

Сегодня на ежедневном Stand-up'е я произнёс перед командой очень проникновенную речь о том, что мы пишем софт для людей и никого не интересует, насколько красиво код будет выглядеть изнутри, если пользователю будет неудобно с ним работать.

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

И, конечно же, я сразу же вспомнил концепцию о достаточно хорошем (good enough) ПО. Итак, вот её основной постулат: мы не стремимся сделать идеально, мы не пишем как попало, мы делаем достаточно хороший продукт.

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

Disclaimer: эта и дальнейшие статьи серии написаны двумя хабраобитателями: honeyman — программистом стартапов, в свободное время экспериментирующим с торговлей на бирже и созданием аналитического софта для этого, в сотрудничестве с kaichik — журналистом и главредом автомобильных проектов. Если вы в предыдущем предложении не заметили слов «финансист», «лицензированные консультативные экономические услуги» и «богатый опыт» — то наверное, это потому, что их там не может быть.

• Часть I: акции, мажоритарии, контроль над компанией.
• Часть II: стоимость акций, биржа, самый лучший способ торговать картошкой, и кого же можно встретить на рынке бирже.
• Часть III: процесс IPO, его польза для компании, основателей и владельцев, а также почему у руководства компании при открытии торгов такой замученный вид.
• Часть IV: влияние IPO на доход от адулт-партнёрок.
• Часть V: жизнь после IPO.
• Часть VI: сложности выбора — два Lamborghini Gallardo или один Aventador?
• Часть VII: про инсайд.
• Часть VIII: о мотивации.

Итак, часть I: акции, мажоритарии, контроль над компанией.

Что такое акции, и для чего они нужны?

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

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

В этой части статьи я напишу о вертикальном маргине. О горизонтальном поговорим в следующей части.

Понятно, что напрашивающийся (и правильный) ответ — «Потому что код приходится не только писать, а и читать». Едва ли этот ответ стоит целого поста, но автор им не ограничивается.

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

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

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

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

Что такое статический класс?

Для начала вспомним что такое статический класс и для чего он нужен. В любом CLI-совместимом языке используется следующая парадигма инкапсуляции глобальных переменных: глобальных перменных нет. Все члены, в том числе и статические, могут быть объявлены только в рамках какого-либо класса, а сами классы могут (но не должны) быть сгруппированы в каком-либо пространстве имен. И если раньше приходилось иммитировать поведение статического класса с помощью закрытого конструктора, то в .NET Framework 2.0 была добавлена поддержка статических классов на уровне платформы. Основное отличие статического класса от обычного, нестатического, в том, что невозможно создать экземпляр этого класса с помощью оператора new. Статические классы по сути являются некой разновидностью простанства имен — только в отличие от последних предназначены для размещения статических переменных и методов а не типов.

Debugger Canvas – это достаточно интересный способ отладки приложений (и не только). Этот плагин для Visual Studio Ultimate дает немного, пока для меня, необычный способ пошаговой отладки в Visual Studio. После установки этого расширения в Visual Studio ничего настраивать не нужно, а увидеть его работу можно сразу же после запуска приложения под отладчиком и установки точки останова. Debugger Canvas автоматически откроет в Visual Studio отдельный таб со своей функциональностью. Идея этого расширения в том, что оно открывает каждый отлаживаемый метод в отдельной области, позволяя на одном экране проследить цепочку вызовов методов (call stack) и более того иметь возможность просматривать значения локальных переменных в предыдущих методах по цепочке, если вы проходили их под отладчиком. Под катом более подробно о функциях и скриншоты.

В этом топике я хочу вам рассказать о взломе т.н. «матан-капчи», пример которой был представлен в недавнем топике Матановая капча на PHP — это просто!.
Прочитав статью автора об этой замечательной капче, мне захотелось написать программу для её распознавания, как говорится just for fun ;)

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

Развитие моего проекта потребовало «прикрутить» в редактор на основе tinyMCE возможность вставлять изображения, которые хранились бы непосредственно на сервере приложения, и что бы это было бесшовно для конечного пользователя. Погуглив совсем немого и найдя все полезное как всегда на stackoverflow.com и изучив все что есть на сегодняшний день по этой теме, я понял, что придется изобретать свой велосипед. Основные мои мотивы были следующие:
Практически все «готовые» открытые реализации используют файловый принцип хранения, когда пользователь загружает сначала файл на сервер, в область хранения, а затем вставляет его в редактор. В итоге получается довольно сложный процесс, и кроме этого, сервер приложения рискует превратиться в файл помойку. Второй мотив — все решения были достаточно сложны и тяжелы. Например, некоторые из них использовали компоненты silverlight, другие тащили за собой кучу внешних зависимостей. В общем, моя цель: написать простой, легкий загрузчик изображений для tinyMCE который работает на MVC. (я думаю, что это будет справедливо для любого движка MVC а не только ASP.NET). В этой статье я расскажу, как просто написать свой загрузчик и плагин для tinyMCE.

Бытует мнение, что программные системы, будучи объектом не совсем материальным, не поддаются старению. И если говорить о старении физическом, то действительно, шансы на то, что буковка “o” в имени класса вдруг от старости ссохнется и превратится в букву “c” – действительно малы. Но вместо старения физического, программные системы стареют морально.  Со временем накапливается груз ошибок за счет неточностей в исходных требованиях, непонимания требований самим заказчиком, архитектурных ошибок или неудачных компромиссных решений; да и ошибки поменьше, типа слабопонятного кода, его высокой связности, отсутствия юнит-тестов и комментариев делают свое черное дело. Все это приводит к накоплению технического долга (о котором шла речь в прошлый раз), из-за которого при добавлении новой возможности в систему приходиться платить «проценты» в виде более высокой стоимости реализации и более низкого качества получаемого результата.