Этот пост будет не о том, как «перевести» код с C# на F#: различные парадигмы делают каждый из этих языков лучшим для своего круга задач. Однако вы сможете оценить все достоинства функционального программирования быстрее, если не будете думать о переводе кода из одной парадигмы в другую. Настало время любопытных, пытливых и готовых изучать совершенно новые вещи. Давайте начнем!

Все материалы из серии переводов русскоязычного сообщества F#-разработчиков вы сможете найти по тегу #fsharplangru.

Здравствуйте! Меня зовут Елена Толмачева. В компании «ДоксВижн» я занимаюсь разработкой пользовательской документации.

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

Так уж сложилось, что в наших проектах ведение технической документации полностью лежит на плечах разработчиков, по принципу: внес изменения в код проекта — актуализировал документацию. Сама документация представляла собой набор Word’овских документов, которая хранилась вместе с исходным кодом под VCS. Данный подход к организации разработки существовал долгое время, но пару лет назад мы решили озаботиться возможностью ведения документации проекта отличными от MS Office средствами.

Всем привет! Недавно начал пользоваться DITA. Как единственный технический писатель в компании, в общем-то, являюсь первопроходцем в данной технологии.

Пишу в DITA. В качестве редакторов попробовал Adobe FrameMaker и oXygen. В качестве выходного формата использую PDF. В целом, базовый шаблон вполне удовлетворяет. Однако, есть желание доработать его, например, под требования ГОСТ. В связи с этим начал изучать технологию публикации DITA в PDF. Своими изысканиями решил поделиться с коллегами по цеху в данной и в дальнейших статьях. Итак…

Работая в конструкторском отделе, я столкнулся с задачей — рассчитать трудоёмкость разработки конструкторской документации. Если брать за основу документ: «Типовые нормативы времени на разработку конструкторской документации. ШИФР 13.01.01" (утв. Минтрудом России 07.03.2014 N 003)», то для расчета трудоёмкости чертежа детали нам необходимы следующие данные:

• Формат чертежа и количество листов
• Масштаб
• Количество размеров на чертеже (включая знаки шероховатости и выносные линии)
• Количество технических требований

Из имеющихся инструментов на предприятии имеем: Kompas 3D v14 и Python 3.5.

В интернете не так много статей о написании программ с использованием API Kompas 3D, и ещё меньше информации о том, как это сделать на Python. Попробую рассказать по шагам, как решалась поставленная задача и на какие грабли приходилось наступать. Статья рассчитана на людей, владеющих основами программирования и знакомых с языком Python. Итак, приступим.

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

Какие мысли вас посещают, когда вы видите выдающиеся работы других людей? Наверняка, вы восхищаетесь ими, как и мы. Но что более важно, возможно, вам интересно, как люди этого добились, как пришли к успеху. Откуда они черпали свое вдохновение? Что они искали и просматривали в интернете? Давайте посмотрим, что интересного может быть в закладках у UI/UX-дизайнера.

Приветствую друзья! Меня зовут Антон, я развиваю сайт ux.pub посвященный графическому редактору Sketch. Очень часто мне на почту приходят вопросы о тонкостях разработки плагинов для Sketch. Я не разработчик и не специалист в создании плагинов, поэтому я решил сделать перевод самого подробного руководства по созданию плагинов от Mike Mariano.

Часть 1  — С чего начать?

Вы хотите начать писать Sketch-плагины и не знаете, с чего начать? Продолжайте читать, так как этот пост как раз для вас!

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

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

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

А еще я ленивый — мед, да еще и ложкой (я решил использовать в статье аналогии с едой).

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

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

В стремлении к уменьшению мне больше всего нравится вот что: в конце остается только то, что реально нужно, только то, что по-настоящему требуется пользователю. Огромная фотка какого-то чувака, пьющего латте? Выкинуть. Кнопки социальных сетей, которые подсасывают кучу левого кода и ломают дизайн страницы? Пинок под зад им. Эта хреновина на JavaScript, которая перехватывает правый клик и показывает кастомное модальное окно? Выставить на мороз!

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

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

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

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


У нас есть печеньки

Вводная

Думаю, много кто хочет открыть своё кафе. Я тоже когда-то хотел открыться в регионе, украсить стены 5-дюймовыми дискетами и вообще сделать такую айтишную романтику с чашкой чая. Но чтобы открыть кафе по самым минимальным прикидкам нужно иметь 2-3 миллиона рублей в зависимости от города.

Мысли Криса Койера

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

От переводчика

Всем привет, с вами Максим Иванов, и сегодня мы поговорим на довольно острую тему в сфере веб-разработки. Как утверждает Крис Койер, frontend-разработчик должен разбираться в очень многих вещах, о которых не все даже и задумываются. Конечно, мы должны понимать, что frontend-разработчик не главный в процессе разработки любого онлайн-сервиса или ПО в целом. На ту же позицию frontend-разработчика вы найдете больше откликов на вакансию, чем на позицию backend-разработчиком. Но почему же тогда Крис Койер считает, что работать frontend-разработчиком сложнее, ибо ты должен специализироваться во всем. Конечно, ситуаций в жизни очень много, разные компании по-разному используют своих специалистов, но в чем наверняка должен разбираться frontend-разработчик? Об этом мы сегодня и поговорим. Жду комментариев на эту тему, а сейчас приступим.

Здравствуй, Хабр.

Непривычно для меня писать статьи спустя такое долгое время, так как я привык к записи материала на видео, где можно свободно что-либо рассказывать. И так уж получилось, что решил написать статью об Intel XDK, но не просто обзор возможностей, а разобрать среду на примере вполне конкретного проекта. Проектом таким для меня стал «клон» игры «Doodle Jump».

Вступление

Четвёртая часть обзора будет посвящена сервису Fabric (первая часть обзора, вторая часть обзора, третья часть обзора).

Достаточно известный ранее сервис Crashlytics с осени 2014 года является частью Fabric — набора специализированных SDK (или, как сказано на официальном сайте, “modular, cross-platform mobile development suite”), каждый из которых возможно интегрировать по отдельности, либо совместно. В своем обзоре я остановлюсь только на Crashlytics Kit — сервисе и SDK, отвечающими за дистрибуцию мобильных приложений.

Система оценки: сервисы оцениваются по 10-балльной шкале по каждому из разделов (Регистрация и интеграция, Основной функционал, Дополнительный функционал, Continuous Integration). Суммарная оценка позволит определить победителя.

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

Привет, Хабр. Хочу рассказать, как создал свое первое iOS приложение и что из этого получилось.

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

Предлагаю читателям «Хабрахабра» перевод статьи «Functional Animation In UX Design: What Makes a Good Transition?» за авторством Nick Babich.



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

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

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

От переводчика. Искал в интернете простой и легко применимый гайдлайн по написанию программ на C++. Мне понравился один из вариантов, и я решил его перевести и опубликовать. Если хабрапользователи хорошо встретят этот топик, могу перевести и другие связанные документы, а также гайдлайны по написанию кода от других компаний.

1 Введение

Настоящий документ содержит рекомендации по написанию программ на языке C++.

Рекомендации основаны на установившихся стандартах, собранных из различных источников, личного опыта, частных требований и потребностей определённых проектов, а также почерпнутых из источников (см. ниже).

Но для появления ещё одного списка рекомендаций, помимо указанных источников, есть несколько причин. Основная причина — их излишняя обобщённость, поскольку зачастую требуется задать частные правила (в особенности правила именования). Данный документ содержит комментарии, что делает его более удобным в использовании при проведении ревизий кода, чем другие уже существующие документы. К тому же, рекомендации по программированию обычно вперемешку содержат описания проблем стиля и технических проблем, что не совсем удобно. Этот документ не содержит каких-либо технических рекомендаций по C++, делая упор на вопросах стиля.