Наверняка многие из вас видели в интернете фотогалереи с заброшенными торговыми центрами, огромными и некогда роскошными. Впечатляющее зрелище, особенно для бизнесмена. Но первая мысль вовсе не о том, сколько денег, инвестированных в развитие, пропало. Она о том, почему это произошло. Да, есть фактор влияния структурных сдвигов экономики, есть и «вина» онлайн-торговли. Но главное — это неумение вовремя перестроиться, адаптироваться, изменить бизнес-модель. Причём не отказываясь от существующей, а встраивая её в новые условия.
Та же история может случиться с проектом внедрения CRM: система простаивает, компания меняет вендора, выбирает более дорогую систему, которая снова простаивает… Замкнутый круг. А между тем, причины неудачи довольно линейны — и в ваших руках сделать внедрение CRM успешным. Делимся опытом, как.

Основываясь на моих любимых статьях по данной теме и личном опыте, вот мои 5 копеек о том, как называть CSS-классы.

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

Если это поле, используйте элемент input

Читать HTML-документ будет гораздо легче.

Пример:

<div class='submit'/> <!-- Чёёё? -->
<input class='submit'/> <!-- Аа, ясно -->

Источник: Рафаэль Гоитер (французская статья)

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

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



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

Некоторое время назад инвестирование в финансовые инструменты не относили к консервативным методам получения дохода, таким, как вложения в валюту или банковский депозит (вклад). Сегодня тренд меняется — в мире финансов начинают править бал высокие технологии, брокерам помогают программы и роботы, нарастает роль big data и сложных инструментов обработки колоссальных массивов информации. Однако всё это не отменяет базы — основных знаний и навыков, понимания структуры инвестирования в активы. И тем более, именно знание азов нужно частному инвестору. Взаимодействие с брокером – это работа в связке с профессиональным участником рынка, который помогает принимать решения, вникать в тренды и анализировать их — рано или поздно это даст синергетический эффект.


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

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

Если вы не врач или специалист смежной с медициной специальности, то вы вряд ли слышали о раке сердца. Но это вовсе не означает, что этой проблемы нет. Она есть, но встречается очень редко. По статистике Клиники Мейо (Mayo Clinic), к ним попадает один пациент примерно раз в год с этим заболеванием. А клиника эта вовсе не маленькая — это один из крупнейших частных медицинских центров мира. Так что же такое рак сердца, и стоит ли бояться еще и его?

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



Но давайте подумаем о таком сдерживающем факторе роста сегментов Интернета вещей, как непонимание владельцами и менеджментом компаний способов ведения бизнеса в условиях новой глобальной информационной экономики, всё более ориентирующейся на многоуровневое «мгновенное» цифровое взаимодействие потребителей, вещей и алгоритмов. Может быть этот фактор и становится главным «тормозом» для IoT?

Социальная сеть Instagram объявила о запуске профилей для бизнеса с набором инструментов для продвижения бренда и коммуникации с клиентами. В ближайшие месяцы новый функционал будет доступен в США, Новой Зеландии и Австралии. В других странах запуск запланирован до конца 2016 года, говорится в официальном блоге соцсети.

Теория систем рассматривает процесс как изменение системы. Действительно, любая деятельность — это действия, направленные на достижение результата, который выражается в том, что система обретает новое состояние. С процессами мы сталкиваемся в разработке, технике, химии и даже социологии. Однако каждый из нас ежедневно является участником рабочих процессов. Как показывает опыт, нередко руководители компаний избегают автоматизации и формализации процессов, им это кажется не совсем демократичным «закручиванием гаек». А напрасно. Грамотное построение и управление процессами в компании любого профиля помогает обеспечить адекватное взаимодействие сотрудников, обусловленное ответственностью и вниманием к срокам. Процессный подход не умер — он лежит в основе множества модных теорий управления разработкой, компанией, персоналом. Сегодня мы расскажем, где встречаются процессы, как ими управлять и нужны ли они вам в принципе.

Не первый раз пробую привлечь внимание [хабр]общества к проблемам микро-, малого и среднего бизнеса в IT. Всё чаще после публикаций стали писать люди: кому-то я помог, кому-то, к сожалению, по разным причинам — нет. Но то, что вопросы поднимаются злободневные — очевидно. Поэтому — продолжаю.

Казалось бы, откуда этот, спорный на первый взгляд, тезис: «ИП под угрозой»?

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

Клиент-серверная архитектура для разработчиков веб-приложений — это примерно как одна из черепах, на которой стоял мир в воззрениях наших предков. Трудно себе представить иное положение вещей. Однако бесчисленное количество веб-приложений сформировало новую потребность — управление данными на фронтенде. Пока нет единого подхода и реализации, есть только отдельные технологии, позволяющие работать с данными на клиенте. Да и с ними никто особо не заморачивается. А между прочим, пора. О том, что уже есть в плане работы с данными на фронтенде и что будет дальше, мы поговорили с Никитой Прокоповым aka tonsky.

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

Как сделать сайт, который понравится пользователю? Какой он должен быть: красивый, с удобной навигацией, с запоминающимся URL? Прежде всего, сайт не должен тормозить — у пользователя должно складываться впечатление, что всё летает. Это первично. Всё остальное решается по мере разработки. О том, как воспринимают сайт пользователи, от чего это зависит и когда производительность решает, мы поговорили с Денисом Мишуновым, frontend-разработчиком (в прошлом контрибьютор в CMS Plone в составе Plone UI Team), автором статей про производительность в Smashing Magazine и активным спикером на профессиональных конференциях (среди которых From The Front, JSConf EU, JSConf Budapest, Smashing Conference, а теперь и HolyJS)



— Расскажи о себе. Какой был путь к web-разработке, почему именно она? Чем ты сейчас занимаешься?

— До того, что сейчас называют веб-разработкой, я дошёл быстро, уверенно и предсказуемо: первый компьютер, первый, никому не нужный, сайт, осознание бренности бытия. Дальше было чтение первых страниц «Программирование на Perl» Ларри Уилла и Тома Кристиансен с депрессивным верблюдом на обложке, повторное осознание бренности бытия и, как следствие, откладывание верблюдокниги. А потом я открыл для себя «Designing with Web Standards» Джеффри Зельдмана. Потом было, конечно же, «Ководство» Лебедева и много всего остального. Но книга Зельдмана была переломной. Хотелось бы сказать что-то красивое типа: «мир веба захватил меня после прочтения», но на самом деле я просто понял, что по сравнению с «конструктор электронных аппаратов» (которых из нас тщетно пытались сделать в институте), интернет-разработчик, а именно так это называлось в начале нулевых, звучит откровенно круче.

Большинство создают внешние ссылки через target="_blank" и не знают одного интересного нюанса — страница, на которую мы попадем таким образом, получит частичный контроль над ссылающейся на нее страницей через js свойство window.opener.

Через window.opener.location мы сможем сделать редирект на, к примеру, фишинговую страницу. Это своего рода tabnabbing, только более продвинутый. Так как жертва меньше всего ожидает подмены страницы, в открытой ранее, доверенной вкладке браузера.

Сегодня православная пасха. В этом году получилась разница в пять недель с католической. А вы никогда не задумывались, почему эта разница варьируется из года в год, а иногда даже обе пасхи совпадают? Если в двух словах, то ответ такой:
пасха во всех христианских церквях празднуется в первое воскресенье после первого полнолуния после дня равноденствия.
И самое интересное, дни равноденствия и полнолуния церковь считает по канонизированным таблицам, а не по реальным астрономическим наблюдениям. У католической церкви таблицы достаточно точны и до сих пор дают правильные результаты, потому что они в 1582 году перешли с юлианского календаря на более точный григорианский. Православная церковь так и не перешла на григорианский и до сих пор живет по юлианскому календарю, который на 13 дней сдвинут и дальше будет сдвигаться на 3 дня за 400 лет. Более того, церковь, чтобы определить, есть ли полнолуние на небе, не смотрит на небо, а смотрит в канонизированные таблицы. Они еще нормально работают у католической церкви, а у православной ошибаются на день примерно за 310 лет и уже накопили достаточно большую ошибку. Вот собственно и вся причина, почему пасхи попадают в разные дни. Для более глубокого понимания давайте разберемся во всех этих календарях.

Опять вернёмся в традиционную область разработки операционных систем (и приложений для микроконтроллеров) — написание драйверов.

Я попробую выделить некоторые общие правила и каноны в этой области. Как всегда — на примере Фантома.

Драйвер — функциональная компонента ОС, ответственная за отношения с определённым подмножеством аппаратуры компьютера.

С лёгкой руки того же Юникса драйвера делятся на блочные и байт-ориентированные. В былые времена классическими примерами были драйвер диска (операции — записать и прочитать сектор диска) и драйвер дисплея (прочитать и записать символ).

В современной реальности, конечно, всё сложнее. Драйвер — типичный инстанс-объект класса, и классов этих до фига и больше. В принципе, интерфейс драйверов пытаются как-то ужать в прокрустово ложе модели read/write, но это самообман. У драйвера сетевой карты есть метод «прочитать MAC-адрес карты» (который, конечно, можно реализовать через properties), а у драйвера USB — целая пачка USB-специфичных операций. Ещё веселее у графических драйверов — какой-нибудь bitblt( startx, starty, destx, desty, xsize, ysize, operation ) — обычное дело.

Цикл жизни драйвера, в целом, может быть описан так:

• Инициализация: драйвер получает ресурсы (но не доступ к своей аппаратуре)
• Поиск аппаратуры: драйвер получает от ядра или находит сам свои аппаратные ресурсы
• Активация — драйвер начинает работу
• Появление/пропадание устройств, если это уместно. См. тот же USB.
• Засыпание/просыпание аппаратуры, если это уместно. В контроллерах часто неиспользуемая аппаратура выключается для экономии.
• Деактивация драйвера — обслуживание запросов прекращается
• Выгрузка драйвера — освобождаются все ресурсы ядра, драйвер не существует.

(Вообще я написал в прошлом году черновик открытой спецификации интерфейса драйвера — см. репозиторий и документ.)

Мне известны три модели построения драйвера:

• Поллинг
• Прерывания
• Нити (threads)

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

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

Далее кратко и без воды:

На конференции «Я.Субботник для дизайнеров» компания «Яндекс» представила собственный шрифт под названием Yandex Sans. Этот универсальный шрифт теперь будет использоваться в сервисах и приложениях «Яндекса». Насколько широко он будет использоваться, в компании пока не решили.

Причины разработки собственного шрифта «Яндекс» объяснил в презентации. Во-первых, у конкурентов тоже есть свои шрифты, поэтому хочется «иметь свой голос». Дизайнеры сказали, что им не хватает возможностей Arial и Textbook. Во-вторых, это экономия финансов: разумнее инвестировать в свой шрифт, чем платить за лицензии.