Highload fwdays — спікери зі Stackoverflow, Netflix, Google, AWS, Rovio | Київ, 5 жовтня
×Закрыть

Профит-Шоу XVII: Николай Палиенко, директор Prom.ua

История проекта Prom.ua, что важно для программиста-предпринимателя на старте, об особенностях мирового рынка, как реализовать свои идеи. Обо всем этом рассказывает Николай Палиенко, основатель и руководитель Prom.ua — крупнейшего бизнес-каталога рунета, которым ежедневно пользуются более 400 тысяч человек.

03:12 — Краткая биография
04:50 — Как все начиналось
07:03 — Первые инвесторы, первые идеи
08:20 — Стратегия развития Prom.ua
13:50 — Как совершенствовался продукт? Стоит ли прислушиваться ко мнению клиентов?
18:01 — Техническая сторона проекта. Предпочтения и особенности на мировом рынке.
21:30 — Есть ли место новым идеям, или направления развития Prom.ua
22:52 — Недостатки украинского рынка
25:08 — Почему так много программистов, и так мало успешных проектов?
30:45 — Проблема старта нового проекта

На новые выпуски Профит-Шоу можно подписаться на YouTube, ВКонтакте и Facebook. Аудиоверсия шоу доступна на PodFM.

Спонсор выпуска — Pipedrive.com. Pipedrive is a CRM-replacing deal management tool. It helps people be super organized and close their deals in less time.

LinkedIn

38 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Коля, а все-таки, чем принципиально отличается аналитик, о котором ты говоришь, от аналитика из ритейла? Это ведь такие же KPI и их динамика. Анализ показателей мало зависит от предметной области.

Денис ты прав, ритейл ( а еще и банки со страховыми) это самые продвинутые в аналитике отрасли. Но специалистов все равно очень мало, которые могут что-то анализировать а не делать презентации с графиками.

А специалистов хороших вообще мало. Это касается не только аналитиков :)

А что в студии со светом???

Это допрос???

Було б дуже зручно, якщо б редакція виклала розшифровку інтерв’ю. Часу слухати немає, а прочитати — можна було б

Спасибо за выпуск, было интересно.
Читал блог о развитии prom.ua и меня, как java разработчика, заинтересовал выбор именно python’a для веб разработки (это обсуждалось здесь — blog.smartweb.com.ua/...03/python.html

Вопрос к Николаю. Для java есть уже зрелые фреймворки по типу RoR, такие как Grails и Play framework. Какую платформу вы бы выбрали сейчас в 2012 году? И почему? Спасибо.

Скорее всего тот же Python, в java для веба я не верю, очень негибкий язык и фреймворками там не всегда поможешь.

в java для веба я не верю,
Что есть веб...

Приходящие в Java постоянно задают вопрос: а где же сайты на Java, что-то их не видно. Java плоха для веба?

Недавно в очередной раз объяснял:
Если специализация в вебе — сайты для домашнего пользователя: агрегаторы новостей, соц сетей, услуг; предложения товаров, эл магазины с относительно несложной логикой — то применение Java врядли будет оправдано. JSP, или что другое — вопрос десятый.

Если специализация — для развитого бизнеса или монструозных гос организаций, высокой нагрузки, сложной бизнес-логики с жирными транзакциями к сложносвязанным данным, глубокая интеграция с корпоративными системами(когда бизнес-транзакция начатая в веб-части должна охватить и транзакцию в другой системе) — то пока две платформы — Java и .NET — имеют весомые преимущества перед php, python, и рельсами. Вот эти то решения обычно и «не видны» домашним пользователям.

Можно сказать и обратное: если хватило Python’а (PHP, Ruby), то нет в приложении сложной бизнес-логики, жирных транзакций, и т.д. и т.п.

Можно сказать и обратное: если хватило Python’а (PHP, Ruby), то нет в приложении сложной бизнес-логики, жирных транзакций, и т.д. и т.п.

Интересно у вас все получается) Можно спросить, где вы увидели корреляцию языка программирования со сложностью бизнес-логики и жирностью транзакций?

Железный аргумент =)

Это не аргумент, это был вполне откровенный ответ на не очень умный вопрос.

О, вот она, трольская сущность!) Вы мне даже настроение подняли.

О, вот она, трольская сущность!) Вы мне даже настроение подняли.

Я давно заметил что на этом сайте первыми кричат что их тролят как раз самые злостные троли.

Java — это уже просто не язык программирования(я не случайно парой поставил .NET, а не C#). И даже как о языке: «пора говорить не как об объектно-ориентированном, а об инфраструктурно-ориентированном».

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

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

Жирность транзакций — тоже самое. Я имею ввиду не транзакции к БД, которые впрочем тоже, если жирные, то... А имею ввиду бизнес-транзакцию. Которая может содержать в себе несколько транзакций к БД И другим подсистемам, серверам.

Трансакції і високі навантаження/маштабування поняття несумісні. Почитайте теорему CAP.
А стосовно потягне не потягне. Java/.NET/Python/Rails один фіг. Добрі спеціалісти можуть піднімати високонавантажені сайти на будь-якій з цих технологій, тільки от питання чи готові ви їм платити стільки скільки вони коштують на ринку.
А різниця в цих платформа в швидкості розробки, коли час копіювання успішної ідеї йде на тижні, та платформа яка дасть вам гнучкість і прискорення розробки дасть вам вижити.
«високі навантаження» на SharePoint виглядає як забавка порівняно з навантаженнями StackOverflow. Бо для високих навантажень, навіть стандартні бібліотеки переписують (див. LMAX, StackOverflow) тому специ вам коштувать приблизно однаково.

Ну і зрештою наші локальні проекти мають «високі навантаження» умовно. Це навіть не позавчорашній день грандів. Шаблони, рецепти рішення давно обжовані, звичайно є особливості і необхідність в практиці, але це для здібної людини не така вже й проблема.

транзакции Сергей, они не в Java и .Net, они в базах данных, а то, что вы написали — это пример работы маркетологов J2EE решений, которые вбили всем в голову, что это их преимущество.

Транзакции бывают к БД, а бывают и логические. Вы весьма узко их видите :)

Транза́кция или транса́кция (англ. transaction, от лат. transactio — совершение, договор) — минимальная логически осмысленная операция, которая имеет смысл и может быть совершена только полностью (или полностью отменена).

Спор же между чисто вебщиками и ынтырпрайщиками да, старый.

Но вот простой вопрос, ваша система: резервирует товар в системе продавца, при оформлении покупателем?

Я не говорю что она обязана это делать. Или что — раз не делает то плоха.

О разнице жирности транзакций и к БД речь.

Тоже с высокой нагрузкой:
Сколько «пингов» в секунду в состоянии обработать система — это одно.

Сколько в секунду ответов выдается на запрос к системе (к десяточку таблиц , а перед этим и после еще и с десяточек бизнес-правил прошустрить) — это другое.

А насчет «работы маркетологов» то это частный случай аргумента «теории заговора».

Теория заговора — нефальсифицируемая штука, а потому нет смысла обращать внимание на такой «аргумент».

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

Давайте не смешивать задачу, требования к конечному функционалу с технической стороной вопроса.

Keep it simple.

Вы наверное просто очень загружены, если пропустили мое: то применение Java врядли будет оправдано.
Добавлю:
Например для prom.ua, контент которого является простым: просто каталог товаров (средства для их изменения продавцами — другой вопрос), и как итоги
1. структуры данных простые, и возможно их, при надобности, вообще просто денормализовать;
2. соотношение чтение/запись — стремится к бесконечности;

выбор решений для энтерпрайз — был бы неоправдано дорогим (по времени разработки и стоимости труда программистов нужного уровня).

То есть, я вообще одобрил выбор Pythonа для вашей задачи.

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

Транзакційна логіка і високі навантаження поняття несумісні. Почитайте теорему CAP. А стосовно потягне не потягне. Java/.NET/Python/Rails один фіг. Добрі спеціалісти можуть піднімати високонавантажені сайти на будь-якій з цих технологій, тільки от питання чи готові ви їм платити стільки скільки вони коштують на ринку.
А різниця в цих платформа в швидкості розробки, коли час копіювання успішної ідеї йде на тижні, та платформа яка дасть вам гнучкість і прискорення розробки дасть вам вижити.
«високі навантаження» на SharePoint виглядає як забавка порівняно з StackOverflow. Бо для високих навантажень, навіть стандартні бібліотеки переписують (див. LMAX, StackOverflow) тому специ вам коштувать приблизно однаково.

Ну і зрештою наші локальні проекти мають «високі навантаження» умовно. Це навіть не позавчорашній день грандів. Шаблони, рецепти рішення давно обжовані, звичайно є особливості і необхідність в практиці, але це для здібної людини не така вже й проблема.

транзакции Сергей, они не в Java и .Net, они в базах данных

JTA и JTS не существуют?

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

Стройте, стройте, а не на форуме рассказывайте о крути технологии Х.
Уделайте всех этих любителей!

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

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

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

Результат — мерило, а не рассуждения. Рассуждения как раз у дрочильщиков, которым женщины «не дают» ;)

Да да, ведь миллиарды мух не могут ошибаться.

Да, да, всякий непризнанный гений мнит остальных мухами :D А себя — опередившим время.

Вы пишите код, а не буковками срамите мух в форумах.

Авось что и правда получится? ;)

P.S.
Мнение одного С++ника которое разделяю:

Если подробно объяснять, то придется писать очень долго и много. Бертранд Мейер на тему ООП талмуд на тысячу страниц написал :)

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

Еще одна сторона медали. Динамическая vs статическая типизация. На маленьких задачах с небольшими коллективами динамические языки удобнее и быстрее в разработке, чем статические. Но стоит увеличить объем, стоит работать над проектом в течении 10-15 лет, стоит сменить большую часть проектной команды, как ситуация поменяется на обратную. И многословная дебильная Java будет много удобнее лаконичного и красивого Ruby.

Евгений Охотников — eao197.blogspot.com/...gworkflame.html

указаный линк — просто верх дилетанства при выборе платформы.

например фраза:

позор Java еще и в том что там до сих пор нет механизма делания thumbnails из картинки, дающего результат с нормальным качеством.

У каждого нормального програмера сразу возникнет вопрос — а какое отношение язык програмирования имеет к «механизму создания превью»? Ну и вопрос, а чем не устраивает тот же imagemagic к которому есть интерфейсы пратически на любом языке?

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

У каждого нормального програмера сразу возникнет вопрос — а какое отношение язык програмирования имеет к «механизму создания превью»? Ну и вопрос, а чем не устраивает тот же imagemagic к которому есть интерфейсы пратически на любом языке?
Я думаю если бы это было легко сделать, то эта функция была бы нормально реализована в стандартной библиотеке либо кем-то из миллионов джава программистов. Imagemagic мы интегрировали пару недель в 2007-м, и решение было рагульным в плане запуска через шелл внешней программы. Есть ли сейчас прогресс в этом направлении даже не знаю.

А вот у меня с стоковым imageio все всегда прекрасно получалось.

4 года — полет нормальный, ни разу не пожалели в выборе.

не критирую ваш выбор, странным кажется то, как он был сделан, если судить по статье с блога, основным аргументом было «хотим писать на питоне, остальное не знаем или надоело»

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

Сколько конфиденциальных данных было сказано )

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

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

футболку з культурнішими написами вдягнути слабО було?

Звук вообще никуда не годится

Подписаться на комментарии