1. Я люблю тебя не за то, кто ты, а за то, кто я, когда я с тобой.
2. Ни один человек не достоин твоих слез. А те, кто их достойны, никогда не заставят тебя плакать.
3. Только потому, что кто-то не любит тебя так, как тебе хочется, не означает, что он не любит тебя всем сердцем.
4. Настоящий друг — это тот, кто будет держать тебя за руку и чувствовать твое сердце.
5. Наихудший способ грустить о ком-то — это быть с ним и понимать, что он никогда не будет твоим.
6. Никогда не прекращай улыбаться, даже когда тебе грустно, потому что кто-то может влюбиться в твою улыбку.
7. Возможно, в этом мире ты лишь человек, но для кого-то ты — весь мир.
8. Не трать времени на человека, который не желает проводить его с тобой.
9. Возможно, Бог хочет, чтобы мы встречали не тех людей, пока мы не встретим ТОГО ЕДИНСТВЕННОГО. Чтобы, когда это в конце концов случится, мы были благодарны.
10. Не плачь, потому что это прошло. Улыбнись, потому что это было.
11. Всегда найдутся люди, которые сделают тебе больно. Нужно продолжать верить людям, просто быть немного осторожнее.
12. Стань лучше и сам пойми, кто ты, прежде чем встретишь нового человека и будешь надеяться, что он поймет тебя.
13. Не прикладывай столько усилий — все лучшее приходит неожиданно.

Источник: Хутір.info

Желая познакомиться с многообещающим 2.0 ресурсом Livents, который недавно так хитро был отрекламирован на хабре. Я прошел регистрацию, немного покликал на кнопочки, и не найдя применения полученным на сайте возможностям, покинул его на неопределенное количество лет. Но мои данные, оставленные при регистрации на сайте, были грубо использованы в попытке ускорить мое возвращение на ресурс: мой почтовый ящик посетило штук 30 писем от вышеозначенного стартапа и все для разных пользователей. Сколько там много разных имен! Но моего, к сожалению, не было. Вот такое (не)приятное знакомтво с функциональной платформой нового детища российской индустрии маргинальных соц-веб-продуктов.

И тут он говорит мне: «Как же это у нас сервис без карт? Это ж не Web 2.0!». Услышав сакраментальное «Web 2.0», я внутренне напрягся. Обычно это означает неделю работы без выходных, для реализации какой-нибудь красивой фигни, увиденной начальством на бескрайних просторах Интернета. Придав лицу умное выражение (и такое бывает), я принялся излагать трудности и опасности разработки приложения для работы с картами. Но мой полет мысли был варварски прерван.

«Есть же GoogleMaps. Там уже все сделано за нас. У них, я слышал, хорошее Api, к тому же бесплатное. Нужно только прикрутить по-быстрому. Работы-то на пару часов».

После ключевых фраз «по-быстрому» и «Работы-то на пару часов» я понял, что сегодняшний секс с девушкой накрылся медным тазом. Да и вообще на ближайшие дни моим постоянным половым партнером становится Internet Explorer.

Аналитики из компании Forrester Research тщательно исследовали феномен, известный нам как правило одного процента, которое в упрощённом виде гласит, что если взять онлайн-группу из 100 человек, то всего лишь один человек будет создавать контент, девять — обеспечивать «интерактив» (оставляя комментарии или предлагая улучшения); остальные 90 пользователей ограничатся просмотром, то есть пропорция 1–9–90… В терминологии Forrester этот феномен называется «социальная технографика». Результаты проведённого опроса изображены на графике.

Все разговоры о корпоративных блогах, в том числе и от самопровозглашенных “гуру” (к коим и меня можно отнести, в принципе), грешат ровно одним — отсутствием конкретики.
Ну то есть на конкретный вопрос заказчика “зачем мне блоги” все отвечают что-то невразумительное о том, что всё зависит от ситуации, от бизнеса и ваще. Понятно, все стараются казаться умными и знающими, при этом не стремятся отвечать за свои слова. Консалтинг же, чего уж там!
Собственно этим же страдала и дискуссия, в которой я принимал участие на конференции о пи*аре и репутации. Уже надоело, в самом деле. Так что попробуем свести основные тезисы этой дискуссии, а также другие мои соображения на тему корпоративного блоггинга в максимально конкретный список тезисов.

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

Наследство

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

На примере профиля видно, как было «до» и что стало «после».

iBeacon является новой технологией, которая построена на основе Bluetooth Low Energy или BLE. Пока iBeacon более всего ассоциируется с Apple. Начиная с 2013 года iBeacon встроена в Apple iOS 7. Впервые пилотный проект был запущен в магазинах Apple в декабре 2013 года и в 2014 году ожидается существенное расширение использования технологии — via Wi-Life

Добрый день, дорогой Хабрахабр!

Сегодня мы познакомимся с реализацией функционала BLE под iOS на основе iBeacon-девайсов от Roximity. Поискал, поспрашивал, пошерстил, вроде как, никто так и не писал о практической стороне вопроса в рунете. Статью делю на две части: про настройку на серверах Roximity и про подкапотную приложений.

Заинтересовавшихся прошу под кат.

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

Мы сделали видео-уроки по языку Swift на основе бесплатной книги The Swift Programming Language от Эппл.



Все 32 урока доступны на нашем сайте. Несколько уроков – под катом.

Статья является своеобразным продолжением статьи «Знакомьтесь, Swift!» за авторством Helecta, а также вольным переводом статьи Developing iOS Apps Using Swift Tutorial Part 2.



Итак, в первой статье мы написали простое Single View приложение, включающее таблицу с несколькими ячейками.
На этот раз мы немного углубимся и сделаем несколько более амбициозных вещей. Мы будем обращаться к API поиска iTunes, парсить ответ, полученный в JSON и отображать результаты в Table View.
На первый взгляд может показаться, что все это довольно сложно и предстоит много работы, но на самом деле это не так. Все описанное выше является достаточно простым функционалом для iOS приложений и каждый уважающий себя iOS разработчик должен это уметь.

Привет, Хабр! 2 июня все мы воочию могли наблюдать, как компания Apple начала творить революцию в стане Objective-C разработчиков, представив миру свой новый язык программирования – Swift. Вместе с этим, она выложила в открытый доступ небольшую документацию по языку, которую мы решили перевести, если на то будет спрос. Предлагаем вашему вниманию перевод первой главы. Если тема будет интересна, то мы продолжим публиковать перевод каждую неделю.

Сегодня речь пойдет о пакете Pandas. Данный пакет делает Python мощным инструментом для анализа данных. Пакет дает возможность строить сводные таблицы, выполнять группировки, предоставляет удобный доступ к табличным данным, а при наличии пакета matplotlib дает возможность рисовать графики на полученных наборах данных. Далее будут показаны основы работы с пакетом, такие как загрузка данных, обращение к полям, фильтрация и построение сводных.

Введение

Добрый день, уважаемые читатели.
В прошлых статьях, на практических примерах, мной были показаны способы решения задач классификации (задача кредитного скоринга) и основ анализа текстовой информации (задача о паспортах). Сегодня же мне бы хотелось коснуться другого класса задач, а именно восстановления регрессии. Задачи данного класса, как правило, используются при прогнозировании.
Для примера решения задачи прогнозирования, я взял набор данных Energy efficiency из крупнейшего репозитория UCI. В качестве инструментов по традиции будем использовать Python c аналитическими пакетами pandas и scikit-learn.

Добрый день уважаемые читатели. В сегодняшней посте я продолжу свой цикл статей посвященный анализу данных на python c помощью модуля Pandas и расскажу один из вариантов использования данного модуля в связке с модулем для машинного обучения scikit-learn. Работа данной связки будет показана на примере задачи про спасенных с "Титаника". Данное задание имеет большую популярность среди людей, только начинающих заниматься анализом данных и машинным обучением.

В прошлой статье я описал, как мы в Иннове используем data mining для предсказания ухода новичков, только начинающих свой путь в ММОРПГ Aion, на основе логов их действий за пару часов или дней, проведенных в игре. Но у нас также есть и ветераны, посвятившие игре месяцы и годы, и они тоже иногда уходят. Мы уже научились с высокой точностью предсказывать угасание их интереса теми же методами data mining.

Примечание переводчика: После публикации статьи с автором связался коммерческий директор из King.com, создателя Candy Crush Saga, и прояснил несколько моментов, после чего автор добавил пару замечаний. Добавленные абзацы отмечены курсивом.

Принудительная монетизация

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

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

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

Одна из сложностей, с которой, по моему опыту, сталкиваются практически все разработчики и дизайнеры, работая над приложениями для Windows 8 и Windows Phone, начинается прямо с порога – с проектирования того, как пользователь будет взаимодействовать с приложением (UX и UI).



Часто разработчик (автор приложения) приходит с некоторой готовой идей и старается напрямую перенести в Windows 8 привычную десктопную, мобильную или веб-функциональность. Обычно эта прямолинейная попытка «портирования» оборачивается стремлением сохранить все, что есть в оригинальном решении, включая схожие шаблоны решения интерфейсных задач и знакомые приемы разработки и написания кода.

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

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

Велосипед

Итак, Вася долго трудился рядовым программистом, ведущим программистом и наконец стал Руководителем. У него есть команда отчаянных головорезов разработчиков в количестве двух единиц. Безусловно талантливых и знающих свое дело специалистов.

Вася получает первый заказ — надо сделать … велосипед.

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



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

Посмотрим как они выкрутятся?

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

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

Картинки кликабельны.

Form builder

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