«Три девицы под окном пряли поздно вечерком.»



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

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

Вскоре «в светлицу вошел царь — стороны той государь» (показан на рисунке). «Во все время разговора...», — ну понятно в общем.
«Собираем лайки нежности — формируем матрицу смежности», — бодро срифмовал он.
Девицы-красавицы с именами Алена, Варвара и Софья засмущались, но лайки (из балалайки) передали.

Вот что там было:

• Алена получила 1 лайк от Софьи и 2 лайка от Варвары.
• Варвара получила по лайку от Алены и Софьи.
• А Софья получила 2 лайка от Алены и 1 от Варвары.

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

Наибольший вес лайков (7 баллов) получила Софья, но титул «мисс Салтан» достался Алене (15 баллов).


После объявления результатов девицы бросились обратились к царю с просьбой рассказать,- откуда взялись эти странные цифры?

Технологии Big Data создавались в качестве ответа на вопрос «как обработать много данных». А что делать, если объем информации не является единственной проблемой? В промышленности и прочих серьезных применениях часто приходится иметь дело с большими данными сложной и переменной структуры, разрозненными массивами информации. Встречаются задачи, способ решения которых наперед не известен, и аналитику необходимы средства исследования исходных данных или результатов вычислений на их основе без привлечения программиста. Нужны инструменты, сочетающие функциональную мощь систем BI (а лучше – превосходящие ее) со способностью к обработке огромных объемов информации.

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

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



Требования понятны. Данные должны отображаться быстро, создавать минимальную нагрузку на СУБД и работа с ними должна быть удобна пользователю. Решения вроде тоже все есть. Но все равно даже в очень успешных проектах применены технологии, которые заставляют предположить, что разработчики решили еще раз придумать “самое лучшее” решение.

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

Давно просили написать про мою жизнь в Болгарии, способы заработка и качества жизни. Прошло уже 4 года как я здесь, у меня сформировалось чёткое представление о стране и её особенностях, решил поделиться с сообществом.



Мой пост для тех, кто задумывается о переезде и пока не знает куда.

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

Информации в сети о заветном маркетплейсе Envato.com достаточно много, но детально расписанный процесс подготовки проектов попадается очень редко. Я сам не раз обращался к успешным авторам, продающим на Themeforest.net, за советом и помощью. Благо есть люди готовые помочь безвозмездно. Я надеюсь, моя статья также будет полезна начинающим авторам или тем, кто собирается стать автором. Ну или, по крайней мере, прольет немного света на темопроизводство.

Как все начиналось

Как я рассказывал в своих предыдущих публикациях, уже несколько лет моя небольшая студия занимается диджитал продакшеном: разработкой web сайтов и мобильных приложений. А разработкой шаблонов мы занялись по рекомендации моего товарища. Однажды он сказал, что это отличный дополнительный заработок для небольшой студии, и, мол, усилий требуется совсем немного для этого. Идея иметь дополнительный заработок, используя ресурс студии, который не загружен по текущим проектам, мне понравилась. Но тогда я еще даже не представлял какое количество времени мы потратим до того момента, как в продаже на Themeforest.net появится наш первый шаблон. Нам для старта продаж понадобилось более полутора лет. Однако, это случай частный и не стоит на него ориентироваться. Я знаю примеры и более стремительного успеха. Но хочу более детально рассказать, почему мы так долго к этому шли и с какими трудностями столкнулись в процессе.

Представьте себе: ваш ребенок умирает от редкой и неизлечимой болезни. Его бьют посторонние люди, и он страдает от жуткой боли. В самом конце он усыхает до размера кошки, становится совсем серым и, наконец, умирает. А потом случается хеппи-энд: вы узнаете, что в роддоме произошла ошибка… Ф-ф-фу, напугал, дур-рак!

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

Привет, друзья! Прототипы — это становой хребет продуктового дизайна. Я расскажу, почему мы в команде используем только hi-fi прототипы и отказались от всех прочих.

Ранее мы уже говорили про структуру приложений и определение принципов навигации. Кул. Но что со всем этим делать дальше? Не вопрос! Конечно, нужно разработать прототип. Прототип нужен для раннего тестирования MVP, для снижения рисков проектирования, для проверки пригодности предлагаемых решений, для показа акционерам, для краудфандинга и для экономии времени при общении с разработчиками. Отовсюду мы слышим стоны. Всем нужен прототип. Мы должны протянуть руку помощи, и мы ее протянем.
И тут у меня для вас 2 новости. Сначала хорошая: плохая новость могла бы быть намного хуже…

Прошло уже более месяца с момента публикации первой части обзора спроса на IT специалистов в Германии.

Что нового:

• Добавились страны: Нидерланды и Мальта.
• Услугами ItRabota начинают пользоваться компании (без посредников).

Спрос по странам:

• Германия:
• Senior/Middle: PHP, JavaScript, Java, NodeJs, iOS/Andorid, .NET, а также QA и devOps
• Нидерланды:
• Senior: PHP, JavaScript, Java, NodeJs
• Мальта:
• Senior/Middle: PHP, JavaScript

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

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

Я — пентестер, и так получилось, что практически на всех проектах, хотя бы отдаленно связанных с анализом инфраструктуры разработчиков, мне встречаются установленные Jenkins и TeamCity (один раз я даже видел Bamboo). Немного гугла, и я выяснил, что это все — так называемые системы непрерывной интеграции. Конечно, в какой-то момент у меня в голове стали возникать вопросы вроде: «А что это вообще за системы такие?» и «Что с ними можно сделать?», естественно, с точки зрения пентестера. Ответив на поставленные вопросы, мы поймем, какую выгоду потенциальный злоумышленник может извлечь и какой вред нанести в рамках экосистемы разработчика, используя лишь имеющуюся в ней систему непрерывной интеграции.

Agile — это модно

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

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

• Во-первых, в силу специфики своей работы, они взаимодействуют напрямую с исходными кодами (утечка которых, во многих случаях может означать значительные убытки для компании).
• Во-вторых — зачастую, для корректной сборки исходных кодов в конечный продукт, пользователи системы создают так называемые сборочные скрипты, которые могут быть реализованы как средствами самой системы непрерывной интеграции, так и с использованием сторонних инструментов (например, скрипты могут загружаться из репозиториев). В простейшем случае, эти скрипты представляют собой batch или bash файлы, т.е. по сути они ограничены только возможностями самой ОС, на которой исполняются. Таким образом, если злоумышленник смог модифицировать сборочный скрипт, он сможет выполнять команды ОС непосредственно на сборочном сервере.

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

В Alconost мы делаем видеоролики о сервисах и приложениях. За 4 года мы перещупали сотни IT-продуктов, среди которых встречаются интересные разработки, достойные поста на Хабре. Например, недавно мы сделали ролик о плагине HelpDesk for JIRA для компании «Тимлид».

Чем интересен этот проект? Тем, что он прямо конкурирует с родным модулем саппорта для «Джиры», который, кстати, сам по себе довольно неплохой, но дорогой (например, 5 юзеров — $1500). Получается, что плагин решает ту же проблему, что и «материнский» продукт, только дешевле.

Кстати, а вот и ролик, который мы сделали:



Чуть больше информации про HelpDesk for JIRA — под катом.

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

Предисловие

Важно! Если Вам хочется побыстрее приступить к технической стороне дела – просто пропустите эту главу.

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

Кстати картинка «человека дождя» на заглавной не просто для привлечения внимания и именно для этого в повествование добавлена «лирика», все события, имена и прочее есть суть фантазии автора. Как обычно, никто ни за что не несет ответственности :)

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

В первой части моей истории про собеседование в Booking.com я рассказал лишь половину, а именно все, что касалось удаленного общения из Москвы. Я остановился на том, что получил письмо от рекрутера с заголовком, который гласил «Interview Invitation To Amsterdam!». Это значило, что скоро мне предстояла поездка в Нидерланды, чтобы лично встретиться с кем-то из компании и пообщаться с глазу на глаз.

Пишу отчет на основе последних 5 месяцев активного развития проекта.

Отчет состоит из 3 частей:
1. Какие IT специалисты сейчас нужны (на примере Германии). Думаю, что это касается и всей Европы, но пока что все устраиваются в Германии.
2. Какие важные моменты я заметил в процессе работы с кандидатами
3. Анонс по функционалу проекта (полезно будет и тем, кто пока что не собирается за границу)

1. Тренды.
Какие специалисты нужны чаще всего
Проект постоянно получает запросы на программистов уровня Senior и Team Lead.
Самые спрашиваемые языки программирования: PHP, JavaScript, NodeJs, Ruby, Scala и Java.
Frameworks не играют очень важной роли, но указывать их все же стоит. Например: Angular, React, Backbone, Zend
Также бывают запросы на UI-UX дизайнеров и QA. Но их заметно меньше.

Число команд, которые используют Wrike для ведения проектов и совместной работы, в декабре превысило 10 000. Компания растет, и год назад мы столкнулись с необходимостью многократно увеличить службу поддержки (с 20 до 60 человек в перспективе).

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

При запуске нового проекта, всегда есть очень много специфических моментов, от которых зависит его жизнеспособность. Если покопаться в Google по запросам «Как запустить стартап», «Проблемы старапов» или «Опыт запуска стартапа», можно найти кучу статей, описывающих гору проблем в начинающихся проектах. Не смотря на свою непохожесть, они все объединены одной общей историей: «детские болезни» и ошибки, которые приводят к феерическому «сексу» с внезапно взбесившимся проектом и кучей неприятностей в придачу. Посему, сегодня будет краткий экскурс в прикладную «сексологию стартапов» с максимально подробным разбором практических моментов.

Легко построить внутренний рынок торговой компании. Там все что-нибудь покупают и продают.

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

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

А можно ли сделать так, чтобы сотрудникам было выгодно продавать вам именно то, что приносит доход фирме?

К моему удивлению, предыдущую статью приняли достаточно тепло. Сегодня продолжим рассмотрение этого вопроса.

Всем привет!
Это перевод второй части руководства по тематической картографии от ребят из axismaps.
Первая часть: Тематическая картография: общие вопросы.

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

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

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

Мне, как дизайнеру, не хочется тратить 90% времени на формирование окружения (структуру, сборщики и другие подобные вещи). А писать HTML и CSS по старинке, я позволить себе не могу. Таким образом, появляется необходимость в среде для «умного» дизайна.

Анти-кастомщина

Какое-то время я был горд проделанной работой. То, тем как поменялись процессы в нашей команде, как мы выходили из полного дизайн-хаоса. Я описывал это в статье «Дизайн масштабируемых проектов». Но меня беспокоило несколько моментов. И ощущение того, что мы написали свою кастомщину (хоть и достойно справляющуюся со своими задачами) все чаще напрягало.