Перевод статьи Джона Скита, известного гуру языка C#, автора книги C# In Depth, сотрудника Google, человека #1 по репутации на stackoverflow.com и наконец героя Jon Skeet Facts. В этой статье Джон доступно объясняет, что представляют из себя карринг и частичное применение функции, концепции, пришедшие из мира функционального программирования. Кроме того, он подробно поясняет в чём их различие. Признаюсь, что я и сам их путал до прочтения этой статьи, поэтому мне показалось полезным сделать перевод.


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

• Те, кто не интересуются функциональным программированием и находят функции высшего порядка запутанными: вы можете пропустить эту статью полностью.
• Те, кто знают всё о функциональном программировании и хорошо понимают разницу между каррингом (currying) и частичным применением функции (partial function application): пожалуйста, внимательно прочтите этот пост и отпишитесь в комментариях, если найдете неточности.
• Те, кто частично знаком с функциональным программированием, и заинтересован узнать больше: отнеситесь к этому посту скептически и внимательно прочтите комментарии. Прочитайте другие статьи более опытных разработчиков для получения дополнительной информации.

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

Думаю, многим разработчикам на управляемом коде всегда интересовало: сколько же байт занимает экземпляр объекта? А каков лимит размера одного объекта в CLR? Существуют ли различия в выделении памяти между 32-битными и 64-битными системами? Если данные вопросы для Вас не пустой звук, тогда прошу под кат.

Очень много приходится работать с текстовыми данными, такими как код, статьи, посты и т.д. В то время когда жил под Linux — пользовался менеджерами истории буфера обмена, которые запоминали, то что попадало в виде текста в буфер и по клику в трее я мог вернуть нужное значение в буфер, не возвращаясь к источнику.
Недавно пришлось большую часть времени проводить в Windows, удовлетворяющей альтернативы для такого простого приложения я не нашел. Что-то в найденных вариантах не устраивало: не свободное ПО, много ненужного функционала (который просто мешал) или работали неудобно для меня (например: получить предыдущее значение буфера, приходилось открывать окно программы). Недолго думая решил сделать, так как мне хотелось.

Поскольку, приложение должно работать исключительно в Windows, было принято решение написать ее на C# — к тому же, никогда ранее на нем ничего не писал — появился повод попробовать.

Задача

• Программа должна слушать и запоминать изменения в текстовом буфере обмена.
• Через контекстное меню в трее или через окно программы по клику на выбранном элементе истории, нужное значение должно автоматически попадать назад в буфер.
• История не должна пропадать после перезагрузки системы

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

Предыдущий перевод (Landing page, которая работает), посвященный дизайну качественных посадочных страниц набрал больше 150 000 просмотров. С тех пор прошло уже много времени и подход к дизайну изменился – все больше становится минималистичных страниц, о которых и пойдет речь в статье.

От переводчика: это перевод статьи Кристиана Глобмайера The Ten Rules of a Zen Programmer. Статья мне понравилась, решил сделать перевод, после окончания перевода загуглил название, нашел вариант перевода: 10 принципов дзен программиста. Отличается от моего, поэтому решил свой вариант перевода все-таки запостить.

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

Одним дождливым утром я сидел за своим столом и думал об эффективной работе. До того, как я начал работать фрилансером, у меня бывало, что я работал много, но никогда не был доволен результатом. Я начал практиковать Дзен в 2006 году. То, что мне пришло в голову через довольно большое время — старые мастера Дзен уже знали сотни лет назад, как сегодняшние программисты должны работать. Хотя я не люблю посты «как быть лучшим программистом», я хочу рассказать о некоторых моих мыслях с того времени. Этот пост будет служить мне напоминанием, но если у вас есть идеи, не стесняйтесь оставлять комментарии.

Друзья! Мы все очень любим (или не любим) поговорить о шаблонах проектирования. Лично я их сильно недолюбливаю, т.к. большинство из них достаточно очевидны для более или менее опытного разработчика, а шаблонность мышления еще никому в жизни не помогала.

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

В повседневной жизни я стараюсь не употреблять слово «программист». Оно для меня несет негативный оттенок и сразу вспоминаются 90-е, когда кого только программистами не называли. Они и картриджи у принтеров меняли и бабушкам-бухгалтерам помогали их первый комп осваивать. Помните это нетленное «Ты же программист!»? В общем дискредитировало себя это слово.

Я как-то привык своих людей называть разработчиками (developers) и для меня программист — это эдакий антипод разработчика. Ну и с годами опыта я познал большое количество антипаттернов для хорошего разработчика, пользоваться которыми он должен как можно реже. Чем реже я их слышу, тем я счастливее. Итак, приступаем.

001. А у меня на компе работает

Эта фраза знакома всем, кто хотя бы несколько месяцев работает в индустрии и просто должна быть исключена из лексикона любого разработчика. Чувак, если ты отправляешь на тестирование код, который не работает у тебя на компе, то тебе не место в профессии! По определению у тебя на компе код всегда работает. Разве может быть иначе? А не работает он у тестировщика, клиента, да кого угодно, потому, что ты не учел какие-то нюансы, различия в окружении, данных, погоде на Марсе и твоя задача выяснить, что именно и исправить, а не пытаться сразу откосить и доказать свою невиновность. Нет ничего страшного в том, что ты чего-то не учел. В моей практике бывали случаи учесть которые мог бы только… Да никто не мог бы!

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

К сожалению, во многих случаях авторы либо забираются в недосягаемые выси многослойных архитектур, что требуется в лучшем случае для 1% проектов, либо ограничиваются общими фразами вроде «код должен быть понятен» или «используйте ООП и паттерны», не опускаясь до подробных объяснений, в чем например измеряется «понятность» кода.

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

В предыдущей статье я рассказал как разработать судоку для windows 8.1, в этой расскажу как портировать приложение на Windows Phone 8 и локализовать его на несколько языков.

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

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

Итак, вернемся к теме поста. Я давно хотел немного больше узнать о комплексных числах, а не только то, что корень из минус единицы равен i. Особенно вызывали интерес фигуры имеющие фрактальную структуру, хотелось понять, что это значит, и как сделать такую визуализацию. Где то на полке стояла книжка по ТФКП, а так же закончился курс по комплексному анализу на курсере, и появилось немного свободного от работы времени. Приступим.

На конференции NDC 2013, недавно прошедшей в Лондоне, Мадс Торгерсен (Mads Torgersen), являющийся одним из разработчиков спецификации языка C#, рассказал в своём докладе “The Future of C#” о возможных нововведениях в нём.

Продолжаем переводить книгу Чеда Фоулера «Страсть к программированию» совместными усилиями. Готов координировать работу с остальными переводчиками.

Глава 8. Будь специалистом

— Каким образом Вы можете добиться падения JVM используя только возможности Java?
В ответ — тишина.
— Вы меня слышите?
— Извините, я не понял Вас. Повторите, пожалуйста, вопрос.

В голосе прозвучало отчаяние. Я знал из своего опыта, что повторение вопроса не поможет. Тем не менее я повторил вопрос, медленно и громко.

— Каким образом Вы можете добиться падения JVM используя только возможности Java?
— Эм… Извините, я никогда не сталкивался с подобной задачей.
— Я уверен, что не сталкивались. Как насчёт такого вопроса: как бы Вы написали программу, которая бы никогда не приводила к сбоям JVM?

Здравствуйте, уважаемые Хабражители!

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

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

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

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

Принцип номер один. Делать свою работу хорошо

Понятие «хорошо» очень субъективное, поэтому расскажу о своих критериях.

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

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

image: эволюция

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

• Кухня-студия (кухня совмещенная с холлом/коридором), три точки освещения.
• Необходимо управлять освещением из двух точек. У входа в квартиру и на кухне.

Варианты решения:

• Покупаем, так называемые, проходные выключатели, ставим три штуки на кухню, три в коридоре — вот оно счастье. Вот только получилось, что от коридора на кухню нужно вести 9 жил кабеля, некрасиво, спрятать некуда.
• Покупаем готовые решения по управлению одним источником с нескольких точек.
  Точных чисел не помню, но получалось что-то около 10000р за точку освещения + 1000р за каждый выключатель, итого 36000р. Жаба.
• Как это ни странно, но эту идею высказала жена, в общем-то далекая от IT: “ А помнишь, ты светофор в Яндексе делал? Может тут тоже что-то сам сообразишь?”
  В самом деле, а почему бы и нет, подумал я?

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

Имеем в наличии гермозону на 4 ряда с 16-тью открытыми стойками в каждом ряду.
Схема кондиционирования: горячие-холодные коридоры, внутренние кондиционеры с внешними испарителями, 3 кондиционера на ряд, то есть 6 кондиционеров на холодный коридор.

Задача: построить систему мониторинга температуры гермозоны с возможностью предупреждения выхода кондиционеров из строя.

Для решения данной задачи решено было использовать сеть 1-wire температурных датчиков и систему мониторинга Zabbix 2.

Решил написать статью, о том, как сделать выгрузку данных в Excel файл по шаблону и считывать данные из Excel.
Началось всё с того, что на работе, дали указание, уйти от MS Office, на бесплатные аналоги.
У нас уже была система выгрузки, основанная на библиотеке “Microsoft.Office. Interop.Excel” и много готовых шаблонов, для выгрузки тех или иных отчётов.
Поэтому надо было найти бесплатную библиотеку, работающую с офисом. И сделать так, чтоб выгрузка работала по той же системе, что и раньше. Ибо переделывать все шаблоны и структуру, не хотелось.
Вот я и наткнулся на OpenXML. И думал, сейчас по быстрому найду решение в интернете и всё готово (т.к. на это было выделено мало времени). Но подходящего решения так и не нашёл, поэтому и решил написать эту статью, для тех у кого будет, такая же проблема.
Саму библиотеку, можно скачать бесплатно с сайта Micrisoft (я использовал в проекте OpenXML sdk 2.5 “ OpenXMLSDKV25.msi ”)
здесь.
После скачивания “OpenXMLSDKV25.msi ”, устанавливаем и заходим в папку
“C:\Program Files\Open XML SDK\V2.5\lib” там лежит библиотека, которая нам понадобится, мы её подключим к проекту (ниже будет описано, как).
Проект был написан на Visual Studio 2010 (Framework 4.0).
Ниже пример шаблона (сделан для теста) “C:\Templates\template.xlsx”.