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

Это перевод статьи Drew Crawford «Why mobile web apps are slow», опубликованной 09 июля 2013. Статья очень интересная, но большая — ошибки возможны — прошу простить и присылать замечания в личку.
Поскольку затронута острая тема, прошу заметить, что переводчик не обязательно разделяет мнение автора статьи!
При переводе текст слегка видоизменялся, поскольку прямой перевод не всегда понятно передает смысл. Для перевода термина «native code» был использован англицизм «нативный код», который понятнее и короче, чем «родной для платформы код». Термин «word processing» переводится как «верстка текста», хотя это немного сужает первоначальный смысл. Термин managed код («управляемый код») не был переведен, так как удачного перевод (на взгляд переводчика) не существует. Под «терминированием» приложения подразумевается его принудительное завершение операционной системой.
Повествование в статье ведется от первого лица: автора статьи.

В подборке инструменты, плагины и другие полезности, облегчающие работу с Twitter Bootstrap. Предыдущая подборка.

Инструменты

Bootstraptor — подборка большого количества бесплатных и премиум тем, в том числе Starter Kit, на основе Bootstrap.

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

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

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

Конечно, я попытаюсь рассказать обо всём по-порядку, начиная с основ. Поэтому, эта статья будет крайне полезна тем, кто только начинает или хочет разобраться с git. Более опытные читатели, возможно, найдут для себя что-то новое, укажут на ошибки или поделятся советом.

Конечно подобный пост найдет голосовательное одобрение только в пламенных сердцах ИТ-подрядчиков, и бойцов прифронтовой кибернетической полосы — но думаю опубликовать будет не лишне!

Работаю АйТишником в крупной компании. В общем, все нормально и замечательно. Как-то однажды наше руководство решило идти в ногу со временем и возникли мысли автоматизироваться. Выбирали довольно долго Электронный документооборот, но либо денег жалко было много платить, либо разработчики какие-то липовые, короче, времени заняло все это переговорно-презентационное безобразие предостаточно. В конечном итоге остановились на некотором решении. Продукт адекватный, разработан под Microsoft Sharepoint 2013 Worklite Docs (я в силу некоторых обстоятельств с этой системой хорошо знаком). В общем выбор пал на него.

Мы собрали воедино все наши корпоративные хотелки, заказали, внедрили — запустили. Все нормально, все работает. Но суть не в этом. Это была присказка.

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

Пора возрождать традицию обзоров стартапов на Хабре.



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

Владельцам стартапов необходимо было ответить на 3 вопроса:

1. Текущая аудитория сайта
2. Доход в месяц
3. Планы

Также, каждый владелец дал свой комментарий: оправдал ли ожидания стартап, какие у него тенденции роста и т.д.

В феврале в Санкт-Петербурге прошла вторая конференция для менеджеров проектов и руководителей групп – «План Б».

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

events.yandex.ru/events/planb/spb-feb-2013/talks — тут выложены видео всех докладов.

Наиболее интересными мне показались Неурядицы при создании сложных проектов/сервисов, Ошибки в стартапах, 10 способов «налажать» во фрилансе.

Коллеги-разработчики выпустили плагин, который умеет извлекать и анализировать плохо структурированную информацию. Проект ориентирован на самый широкий круг пользователей, в частности будет полезен владельцам интернет-магазинов и их клиентам. Что это и как работает — на видео:

Wizee Шопинг — это мобильный гид по торговым центрам, который позволяет всегда иметь под рукой карты торговых центров, а также быть в курсе акций и скидок ТЦ, искать нужные магазины, рестораны, банкоматы и многое другое.

В Wizee собрано 140 торговых центров в 10 городах России и Украины. Приложение доступно для iPhone, iPad, Android и Windows Phone.

Мы уже писали о нашем стартапе на Хабре тут, тут и тут.

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

Этот топик — ответ на топик "Пора завязывать использовать символы табуляции в коде".
Я хотел было ответить к комментариях, но в силу объема и желания независимости от исходного топика решил создать новый топик.

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

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

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

Недавно мы перевели всю Почту на JS-шаблонизатор и JSON-данные.

Привет!

О плагине JsTree на хабре упоминалось лишь в далеком 2009 году. С тех времен все довольно сильно поменялось. Плагин активно развивается. Страница проекта на гитхабе.

Учитывая специфику проекта, над которым сейчас работаю(справочная система), этот плагин оказался просто незаменимым, и я использую 90% его функционала с превеликим удовольствием. И я до сих пор не видел такой же мощной альтернативы.



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

Что мы имеем?

• Построение дерева на основе html разметки, json и xml формата
• Drag & drop с тонкой настройкой возможности перемещения нодов по дереву
• Динамическое добавление/удаление/изменение нодов
• Возможность построения нескольких деревьев на одной странице и манипуляция нодами между этими деревьями
• Возможность присвоения нодам произвольных типов (file, folder, drive, да какой угодно), и указать отдельное поведения для каждого
• Поддержка тем оформления (на скрине в начале статьи пример того, как это реализовал я)
• Управление с клавиатуры
• Использование нативных и кастомных чекбоксов
• AJAX подгрузка нодов, запоминание состояния дерева
• Плагин красиво и читабельно написан, позволяет писать дополнительные плагины к нему и без проблем кастомизировать.
• Удобная система байндингов для обработки событий
• Мультиязычность
• Управление анимацией раскрытия
• Поиск по дереву
• Кастомное контекстное меню
• Поддержка браузеров: IE 6+, Firefox 2+, Safari 3+, Opera 9+, Chrome
• Мини-фича, которая меня особенно порадовала — плагин wholerow — выделения нода во всю ширину. А-ля mac style

Вопрос о столах поднимался несколько раз (раз, два).

Однако, на чем же мы сидим перед столом?

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

Все мы работаем с компьютером и порой не замечаем, на чем же мы сидим.

Оказывается наши санитарные правила и нормы (СанПиН 2.2.2/2.4.1340-03) достаточно хорошо описывают удобный эргономичный стул для работы взрослых за компьютером!

А какой стул правильный?

Что может быть лучшим подарком на день знаний для программиста? Конечно, полезная книга ;) Поэтому команда переводчиков «Pro Git» поднапряглась и доделала перевод книги на русский язык.

«Pro Git» — это довольно обширная обучающая книга о Git от Скотта Шакона — активного участника разработки проектов Git и GitHub. Автор рассматривает в тексте всевозможные аспекты работы с Git'ом, начиная с установки программы и базовых принципов работы децентрализованных систем контроля версий, и заканчивая рассмотрением внутреннего устройства Git'а и созданием валидных объектов в базе Git'а собственными руками. Несмотря на довольно обширный материал и затрагивание довольно специфических тем, книга написана довольно простым языком, содержит массу примеров и иллюстраций, и поэтому должна быть понятна и новичкам, только начинающим знакомиться с системами контроля версий.

Последняя версия перевода книги доступна в форматах pdf, epub, mobi.
Также доступна онлайн-версия перевода, но она, к сожалению, не обновлялась с мая.

Недавно, я столкнулся с некоторыми проблемами при разработке проекта на Drupal 7 (при переходе на Drupal 7), но речь не о них. В поисках решений, я натолкнулся на статью "The Drupal Crisis", одного из разработчиков Drupal — Daniel F. Kudwien, которая пролила свет на происходящее в кузнице Drupal. Сразу скажу, что большая часть проблем описанных в статье уже не актуальна, т.к. статья прошлогодняя. Тем не менее многим будет интересно ознакомиться с ее переводом.

Хочу поделиться ссылками на несколько полезных сервисов. Некоторые из них помогут сэкономить время, другие — сделают за Вас незнакомую/нелюбимую работу. Список разбит по категориям, чтобы было легче ориентироваться.

Сервисы опросов
userreport.com (добавил Romanych)
simpoll.ru
webanketa.com (добавил mihass)

Кнопки постинга в социальные сети
Кнопка от Яндекса
addthis.com (добавил UksusoFF)
share42.com

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

Представим, что в компании есть отлаженный процесс регулярного поступления заказов (звонков, заявок). И есть несколько возможных исполнителей, которые могут выполнить эту работу.
Задача усложняется, если исполнитель выполняет работу на территории заказчика. А услуга, которую он оказывает — вполне может быть выполнена без поддержки компании работодателя. Скажем, договорившись за полцены от официальной цены. Знакомо? Сантехники, репетиторы или даже девушки по вызову – все эти бизнесы остаются халтурами низкого уровня, во многом из-за сложности контроля со стороны работодателя. А диспетчеру, выполняющему эту работу, придется стать ангелом, чтобы распределить все заказы и никого не обидеть.

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

TryGit — интерактивный обучающий курс по Github в стиле Codecademy. Курс состоит из 25 мини-уроков, которые знакомят пользователя с базовыми понятиями и основными командами git, при этом ученик своими руками вводит команды в консоль, смотрит результат и читает сопровождающие надписи с объяснением происходящего.



Вот таким в будущем должно стать обучение в школах!

Конечно, 15-минутное введение не заменит полноценного учебника. Для обучения можно рекомендовать бесплатную книгу Pro Git и видеокурс Getting Git.