Привет!

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

Но давайте начну с начала. Итак, страна поручила вам построить ракету.

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

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

Итак, мы нашли в интернете бесплатные и условно-бесплатные инструменты для роста вашего бизнеса. Когда они дадут вам желаемый результат, вы можете оформить платную подписку.

Вы полны решимости выпустить свою разработку на массовый рынок.

Первый камень преткновения, с которым сталкиваются многие — как делать качественный корпус устройства мелкими сериями?

Как сделать из 3D-печатной модели «конфетку», которую и продавать будет не стыдно?

Один из вариантов — обработка и покраска. О тонкостях окраски полиамида — под катом. Много фото!

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

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

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

Вы запускаете приложение и видите следующее:



Хм. Что-то тут не так. Сверху встроено видео, но текст в нем — на языке, которого вы не понимаете. Формулировки какие-то странные, а надпись на кнопке даже не влезает на саму кнопку. Как такое может нравиться людям?

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

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

Прежде, чем говорить об успехе, давайте поговорим о причинах поражений, чтобы иметь возможность их избежать и тем самым повысить свои шансы на успех. Относительно недавно вышло замечательное исследование про топ 20 причин провалов стартапов. В нем описаны вроде бы очевидные вещи, о которых так или иначе думает каждый предприниматель, но если разобрать каждый пункт отдельно, то можно найти много интересных неочевидных фактов:

Прошло чуть больше года с момента публикации моей второй статьи о дизайне корпуса персонального компьютера в форм-факторе UCFF PC. За это время мне удалось запустить первую партию в производство и начать онлайн продажи не только корпусов, но и конфигураций на его основе. Особенно радостно, что проект по большей части состоялся благодаря поддержке и интересу со стороны читателей Хабрахабр сообщества.

За последний год пришлось довольно много работать с Model/View фреймворком Qt. Приходилось как писать собственные модели, так и переделывать существующие. И вот, после созерцания очередного творения, решил представить общественности некоторые наработки.

Начнем с очевидного:

Не используйте виджеты

Все эти QTableWidget, QListWidget и QTreeWidget — не для вас.

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

Одни плюсы, а минусов, при этом, не замечено.

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

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



В статье ниже я рассмотрю концепцию “обучения во взаимодействии” на примере абстрактной web-системы. Данный подход хорошо можно объяснить примером из современного игрового мира. Сначала вы проходите tutorial. Вам на плечи не вешают сразу килотонны обучающего материала. Вас ведут по ранней стадии игры, в нужное время выдавая подсказки. Например, при первом взаимодействии с новым объектом игры. Накапливается положительный опыт. Вы обучаетесь взаимодействовать. Рискну предположить, что скорее всего Вы считаете себя продвинутым пользователем, когда речь касается приложений. Как и большинство из них вы мгновенно жмёте на кнопку “Пропустить” / “Приступить к работе” …

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



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

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

Поскольку основное предназначение QML — это создание интерфейсов, то в соответствии с шаблоном MVC, на нем реализуются представление и контроль. Для реализации же модели, совершенно логично напрашивается C++. Здесь у нас будет гораздо меньше ограничений и мы сможем реализовать модель любой сложности. Кроме того, если значительная часть программы написана на C++ и данные поступают именно оттуда, то лучше всего там же поместить и модель.

От использования такой модели может отпугнуть кажущаяся сложность реализации. Я не стану спорить с тем, что C++ не самый простой язык. Он посложнее QML и требует больше осторожности, чтобы не выстрелить себе в ногу, это факт. Несмотря на это, на практике не все так уж и страшно.

Во-первых, не будем забывать, что мы пишем не на чистом С++, а с использованием Qt. Такие вещи как parent-child в QObject, implicit sharing для контейнеров, сигналы и слоты, QVariant и многое другое очень сильно упрощают и автоматизируют работу с памятью, чем избавляют разработчика от массы головной боли и повышают надежность. Иногда даже создается впечатление, что пишешь на динамическом языке программирования. Это же сокращает пропасть между QML и C++, делая переход между ними более-менее плавным.

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

В общем, освоить C++-модели очень даже стоит. В особенности это касается QAbstractItemModel, с которой мы и начнем.

Model-View в QML:

• Model-View в QML. Часть нулевая, вводная
• Model-View в QML. Часть первая: Представления на основе готовых компонентов
• Model-View в QML. Часть вторая: Кастомные представления
• Model-View в QML. Часть третья: Модели в QML и JavaScript
• Model-View в QML. Часть четвертая: C++-модели

Анды, высота 1564 метра, чистейший горный воздух, остро пахнущий соляркой. Голая каменистая площадка, четыре купола и три контейнера — купола для телескопов, а контейнеры поменьше — жилой для сторожа или инженеров, санузел, мастерская размером с санузел, плюс купол для стойки Циски и линейки аккумуляторов ИБП. Вокруг — забор из металлической сетки.

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

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

Простая работа, говорили они. Нужен сисадмин, говорили они. Карлос увидел нас, поздоровался и сразу предупредил на своём ломаном испанском:
— Видишь облака — беги. Если начнётся дождь, всё, совсем конец!

Но акцент мы не разобрали, поэтому его не поняли.

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

Клиенту неважно насколько красив ваш код, но ему важен результат. Качественный код нужен фирме, т.к. он надёжней и в будущем его будет легче поддерживать.

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

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

Привет.

За последнее время к нам в консультацю стало поступать много вопросов, ответы на которые будут интересны индивидуальным предпринимателям и небольшим организациям. Вначале мы хотели сделать «Юридический FAQ», но потом поняли, что информации собралось очень много и в обычный FAQ она не поместится. Поэтому мы создали этот блог, где будем доступным языком рассказывать о некоторых моментах ведения малого бизнеса и обо всем новом, что происходит на нашем сервисе Мое Дело.org

Сегодня топик будет о том, как грамотно организовать работу с заказчиками, находящимися в других городах.

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

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

Введение

Я математик-программист. Самый большой скачок в своей карьере я совершил, когда научился говорить:«Я ничего не понимаю!» Сейчас мне не стыдно сказать светилу науки, что мне читает лекцию, что я не понимаю, о чём оно, светило, мне говорит. И это очень сложно. Да, признаться в своём неведении сложно и стыдно. Кому понравится признаваться в том, что он не знает азов чего-то-там. В силу своей профессии я должен присутствовать на большом количестве презентаций и лекций, где, признаюсь, в подавляющем большинстве случаев мне хочется спать, потому что я ничего не понимаю. А не понимаю я потому, что огромная проблема текущей ситуации в науке кроется в математике. Она предполагает, что все слушатели знакомы с абсолютно всеми областями математики (что абсурдно). Признаться в том, что вы не знаете, что такое производная (о том, что это — чуть позже) — стыдно.

Но я научился говорить, что я не знаю, что такое умножение. Да, я не знаю, что такое подалгебра над алгеброй Ли. Да, я не знаю, зачем нужны в жизни квадратные уравнения. К слову, если вы уверены, что вы знаете, то нам есть над чем поговорить! Математика — это серия фокусов. Математики стараются запутать и запугать публику; там, где нет замешательства, нет репутации, нет авторитета. Да, это престижно говорить как можно более абстрактным языком, что есть по себе полная чушь.

Какой контент повышает продажи, как его делать, и какие подводные камни. Cоздатель маркетинговой стартегии Amazon, NBC, GM, HP и основатель компании KISSmetrics Неил Патель дает советы, как рассказывать о продуктах и услугах в 15 разных форматах.

Материал перевела команда Newочём для Relap.io.

pro-cras-ti-na-tion |prəˌkrastəˈnāSHən, prō-|
существительное
задержка или откладывание чего-либо: первый совет — избегайте прокрастинации.

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

Избегать прокрастинации. Так элегантно в своей простоте…

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

Нет, «избегайте прокрастинации» — хороший совет только для не настоящих прокрастинаторов. Для тех, кто говорит «Я захожу на Facebook несколько раз в день на работе. Я такой прокрастинатор!». Это те люди, которые будут говорить настоящему прокрастинатору «Не откладывай дела на потом и у тебя все будет хорошо».

Дело в том, что ни словари ни не настоящие прокрастинаторы не понимают, что для настоящих прокрастинаторов прокрастинация — не дополнительная опция. Это что-то, что они не знают как не делать.

Open Source проекты с каждым днём набирают всё большие обороты, появляются новые, активно развиваются популярные.
Такие проекты как Bootstrap, Angular.js, Elasticsearch, Symfony Framework, Swift и многие другие привлекают новых разработчиков, их сообщество растёт. Всё это даёт огромный рост проектам, а самим разработчикам интересно поучаствовать в разработке чего-то, чем пользуется весь мир.

Я, как и многие другие программисты, не устоял и также время от времени участвую в разработке Open Source проектов, в основном на PHP. Но когда я начинал, я столкнулся с проблемой — я не знал, как правильно организовать процесс «контрибьютинга», с чего начать, как сделать так, чтобы мой Pull Request рассмотрели и т.д.

Всем начинающим «контрибьютерам», которые столкнулись с похожим проблемами, добро пожаловать под кат.