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

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

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

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

Есть набор художественных книг. На данный момент их около пятидесяти. Вы можете выбрать любую из книг для изучения английского языка.
Каждая книга разбита на предложения как показано на рисунке ниже.

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

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

В промежутке времени между переквалификацией с Back-end программиста на Front-end, мне пришлось писать код для RoR приложения (да-да и тесты были). Интересным для меня показалась своеобразная атмосфера сообщества рубистов, которые очень строго относятся к написанию кода и если ты пишешь плохо, то тебе могут поломать пальцы не простить. Ведь код должен быть максимально простым и читабельным.

Это же правило применимо и к тестам (как по мне то, они должны быть на порядок проще чем сам код). В дополнение, в тестах есть свое золотое правило — One Expectation per Test. Не нужно писать кучу expect/assert/should вызовов в одном тесте, просто перестаньте это делать! И не забывайте, что тесты это тоже код, а copy-paste — плохая практика.

Для наступления полного и тотального счастья в плане бэкапов информации на рабочем сервере решил отказаться от Acronis True Image в пользу обычной архивации данных с помощью 7-Zip.

Для выполнения поставленной задачи естественно использовал консольную версию архиватора.

Думаю, практически все обитатели Хабра (и я в том числе) ненавидят домашнюю уборку. Все эти горы грязной посуды, кучки разбросанных вещей и анекдоты в стиле «женщины моют посуду после еды, мужчины – перед едой» и рассказы про живность в кружке из-под чая, собственно, довольно обыденная вещь. До жены я практически так и жил ) При этом умудрялся ещё проходить еженедельные проверки комнат в общаге, устраивать вечеринки, что-то готовить и не отравиться. А также искал и находил нужную вещь в своём «творческом беспорядке». У меня «датчик необходимости уборки» включался уже когда в квартире невозможно было ходить, но потом зато квартира блестела чистотой.

Так как мужской праздник прошёл, и, я надеюсь, отметили вы его преотлично, скорее всего после этого беспределья нужно будет навести порядок. Так как информации о мужской точке зрения на уборку вообще нигде нет, решил поделиться несколькими советами по уборке и вообще поддержанию квартиры\дома в чистоте. Эдакий Home GTD.

От переводчика:
Многие знают, что ffmpeg — это сила, но не все знают, какая именно. Он многогранен и безграничен, а его man объёмен и местами малопонятен, лишь немногие постигли дао профессиональной работы с ним. И тем не менее, этот инструмент может быть полезен почти всем, кто хоть иногда работает с видео и звуком, даже на бытовом уровне. О некоторых полезных консольных командах ffmpeg и пойдёт речь в статье. В некоторых местах я взял на себя смелость вставить ссылки на поясняющие статьи.

ffmpeg — это кроссплатформенная open-source библиотека для обработки видео- и аудиофайлов. Я собрал 19 полезных и удивительных команд, покрывающих почти все нужды: конвертация видео, извлечение звуковой дорожки, конвертирование для iPod или PSP, и многое другое.

1. Получение информации о видеофайле

ffmpeg -i video.avi

2. Превратить набор картинок в видео

ffmpeg -f image2 -i image%d.jpg video.mpg

Эта команда преобразует все картинки из текущей директории (названные image1.jpg, image2.jpg и т.д.) в видеофайл video.mpg

(примечание переводчика: мне больше нравится такой формат:

ffmpeg -r 12 -y -i "image_%010d.png" output.mpg

здесь задаётся frame rate (12) для видео, формат «image_%010d.png» означает, что картинки будут искаться в виде image_0000000001.png, image_0000000002.png и тд, то есть, в формате printf)

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

На Хабре довольно много упоминаний о BDD. К сожалению, статьи, которые я читал, так и не дали мне ответа на вопрос «а зачем мне все это нужно?» Ответ пришел с неожиданной стороны. Когда я всерьез занялся вопросом автоматизации приемочного тестирования, мне под руку попалась книга Gojko Adzic (не уверен в транскрипции, поэтому не стал переводить имя автора) Specification By Example.
Читая ее, я не уставал удивляться: каждая новая глава описывала шишки, которые я набивал на своем личном опыте, и предлагала решения аналогичные или лучшие, чем те, к которым я приходил сам методом проб и ошибок.

Эта статья – первая в цикле «BDD для прагматиков». В ней описаны ключевые элементы наиболее эффективного, на мой взгляд, процесса разработки коммерческого ПО в современных условиях. Два продолжения будут посвящены работе со SpecFlow и автоматизации приемочного тестирования.

Привет, Хабр!

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

Зачем это может понадобиться — под катом.

— Тебе так повезло, что ты программист. Хотел бы я быть программистом.
— А почему ты не научишься?
— Я пытался, заходил на codeacademy и другие сайты, но это не моё.
— Да, программирование, действительно, не для всех.
— Тебе хорошо платят и ты можешь создавать разные вещи. Почти каждый день к тебе поступают сумасшедшие предложения минимум на 100 тысяч долларов.
— Да, это очень лестно. Немножко сносит крышу, если честно.
— Ты получаешь свою долю в компании, все уважают инженеров. Ты можешь воплотить любую идею в приложение и стать богатым. И тебе не нужно для этого никого нанимать.
— Вообще-то программирование делает меня несчастным.

Краткое содержание:

Возьмем немного функций высшего порядка, добавим частичное применение функций, приправим fold с map-ом и получим Javascript DSL для работы с DOM.

Человеческим языком:
Простое и понятное введение в функциональное программирование на чистом и понятном Javascript.

В отличие от «Через тернии к Haskell» все разжевано (возможно даже слишком) и разложено по полочкам.

Прочтение статьи развоплотит миф о неприменимости ФП в реальной жизни. Вы сможете смотреть на решение одной и той же задачи с разных точек зрения. Прямо как на картинке.

Вторая часть ПЕРЕВОДА короткого и жесткого введения в Haskell. С первой можно ознакомиться здесь

Оригинал здесь

• Чертовски сложная часть
  
  • Разбираемся с IO
  • Объяснение трюка с IO
  • Монады
    
    • Maybe это монада
    • Монада списков
    
    
  
  
• Приложение
  
  • Еще несколько слов о бесконечном дереве
  
  

Первая часть короткого и жесткого введения в Haskell. Вторую часть можно найти здесь

tl;dr: Очень краткое и сжатое введение в Haskell.

• Введение
  
  • Установка
  • Без паники
  • Самые основы Haskell
    
    • Объявление функций
    • Пример использование типов
    
    
  
  
• Необходимый минимум из Haskell
  
  • Выражения
    
    • Арифметические
    • Логические
    • Возведение в степень
    • Списки
    • Строки
    • Кортежи
    • Разбираемся со скобками
    
    
  • Полезные вещи для записи функций
  
  
• Сложная часть
  
  • Функциональный стиль
    
    • Функции высшего порядка
    
    
  • Типы
    
    • Вывод типов
    • Создание новых типов
    • Рекурсивные типы
    • Деревья
    
    
  • Бесконечные структуры
  
  

UPD. Если туториал вам понравился, черкните пару строк автору оригинальной статьи. Человеку будет приятно ;)

Уважаемые читатели!
Как психолог я чувствую необходимость и считаю своим долгом вселить веру в IT-специалистов и поделиться своим видением назревших проблем. В начале XXI столетия без ваших способностей и ваших идей сложно будет обойтись. Очевидно, что виртуальная информационная сеть растет и совершенствуется с огромной скоростью по всему миру, расширяет возможности развития и существования общества в целом, но и накладывает все новые и новые поведенческие шаблоны. Развитие компьютерных технологий – хороший бизнес, как за рубежом, так и в Украине. Одно только смущает: где же во всем этом процессе человек? Да-да, обычный программист, а есть ли среди них «обычные»? А дальше о главном и коротко.

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

Вот простой пример, как вы ответите на следующий вопрос: сколько значимых типов из .NET Framework содержит конструкторы по умолчанию? Интуитивным ответом кажется "все", и будете не правы, поскольку на самом деле, ни один из значимых типов .NET Framework не содержит конструктора по умолчанию.

От переводчика: The Codeless Code — сборник побасенок о философии программирования. Побасенки в сборнике разные — некоторые весьма кровожадные, некоторые достаточно хардкорные с технической точки зрения (родной язык автора — Java), но встречаются очень емкие. Представляю вам перевод семи наиболее полюбившихся мне историй, остальные 30+ (новые добавляются каждую неделю) можно найти на сайте.

Пустяк

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

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

Мастер ответил: «Здесь есть изъян, и я размышляю, как лучше его исправить.»

В этой статье я детально исследую примеси в JavaScript, и покажу менее общепринятую, но, на мой взгляд, более естественную стратегию «примешивания», которую, надеюсь, вы найдете полезной. Закончу я матрицей результатов профилирования, подводящей итог влиянию на производительность каждой техники. (Большое спасибо блистательному @kitcambridge за ревью и улучшение кода, на котором основан этот пост!)

Повторное использование функций

В JavaScript каждый объект ссылается на объект-прототип, из которого он может наследовать свойства. Прототипы — отличные инструменты для повторного использования кода: один экземпляр прототипа может определять свойства бесконечного числа зависимых сущностей. Прототипы могут так же наследоваться от других прототипов, формируя, таким образом, цепочки прототипов, которые более-менее повторяют иерархии наследования «классовых» языков типа Java and C++. Многоэтажные иерархии наследования иногда бывают полезны при описании природного порядка вещей, но, если первичным мотивом служит повторное использование кода, такие иерархии могут быстро стать искривленными лабиринтами бессмысленных субклассов, утомительных избыточностей и неуправлямой логики («кнопка — это прямоугольник или контрол? Вот что, давайте унаследуем Button от Rectangle, а Rectangle может наследоваться от Control… так, стоп…»).

...Skype — это дьявольски хитрая программа, написанная бесспорно талантливыми людьми..._{Крис Касперски}

Доброго времени суток!

Skype сейчас я встречаю чаще на компьютерах чем другие IM клиенты, мне он практически заменил icq, вся рабочая переписка ведется в skype, но речь пойдет не о том, что лучше или популярней. Часто бывает так, что участвуешь сразу в нескольких чатах где количество участников превышает 10, что собственно и приводит к тому, что на рабочем столе и в трее постоянно обновляется количество новых сообщений, а также уведомления в виде всплывающих сообщений, а теперь представьте что у вас 3 окна чата с друзьями, 1 с вашим боссом, другой с девушкой — все это в сумме начинает запутывать, отвлекать и порой раздражать. Хотелось бы расставить приоритеты…

Раньше я чаще всего настраивал «политику» уведомлений только через глобальные настройки программы
Случилось так, что я узнал, что в каждом окне чата skype возможно использование команд, например /alertsoff отключит уведомления для конкретного окна чата, соответственно /alertson включит их обратно.
Поискав немного я наткнулся на некое how-to, оказывается у skype чата довольно много текстовых команд, подобие IRC команд. Далее я постарался попробовать все возможные из них на двух имеющихся у меня платформах, как оказалось не все и не везде работает… Прошу под кат.

В первый раз я услышал о CQRS, когда устроился на новую работу. В компании, в которой работаю и по сей день, мне сразу сказали что на проекте, над которым я буду работать используется CQRS, Event Sourcing, и MongoDB в качестве базы данных. Из этого всего я слышал только о MongoDB. Попытавшись вникнуть в CQRS, я не сразу понял все тонкости данного подхода, но почему-то мне понравилась идея разделения модели взаимодействия с данными на две — read и write. Возможно потому что она как-то перекликалась с парадигмой программирования “разделение обязанностей”, возможно потому что была очень в духе DDD.

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

Сразу хочу уточнить что я работал только со связкой CQRS + Event Sourcing, и никогда не пробовал просто CQRS, так как мне кажется что без Event Sourcing он теряет очень много бенефитов. В качестве CQRS фреймворка я буду использовать наш корпоративный Paralect.Domain. Он чем-то лучше других, чем то хуже. В любом случае советую вам ознакомиться и с остальными. Я здесь упомяну только несколько фреймворков для .NET. Наиболее популярные это NCQRS, Lokad CQRS, SimpleCQRS. Так же можете посмотреть на Event Store Джонатана Оливера с поддержкой огромного количества различных баз данных.

Начнем с CQRS

Что же такое CQRS?
CQRS расшифровывается как Command Query Responsibility Segregation (разделение ответственности на команды и запросы). Это паттерн проектирования, о котором я впервые услышал от Грега Янга (Greg Young). В его основе лежит простое понятие, что вы можете использовать разные модели для обновления и чтения информации. Однако это простое понятие ведет к серьёзным последствиям в проектировании информационных систем. (с) Мартин Фаулер

В далекие времена, для IT-индустрии это 70-е годы прошлого века, ученые-математики (так раньше назывались программисты) сражались как Дон-Кихоты в неравном бою с компьютерами, которые тогда были размером с маленькие ветряные мельницы. Задачи ставились серьезные: поиск вражеских подлодок в океане по снимкам с орбиты, расчет баллистики ракет дальнего действия, и прочее. Для их решения компьютер должен оперировать действительными числами, которых, как известно, континуум, тогда как память конечна. Поэтому приходится отображать этот континуум на конечное множество нулей и единиц. В поисках компромисса между скоростью, размером и точностью представления ученые предложили числа с плавающей запятой (или плавающей точкой, если по-буржуйски).

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