Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Стоит ли использовать РНР (Symfony) для написания сайта с блогами + интернет.магазин по ходу?
Или лучше делать с использованием Python?
Блоги/обзоры/статьи — сотни в неделю, меняются.
Товарные позиции — десятки тысяч, с изменяющимися промо-предложениями.
Можете попробовать wp/woocommerce.
Есть репозиторий для heroku/postgresql.
github.com/php4dev/heroku-wordpress
Хорошего Вам дня!
Если нужен здоровый проект без лапшокода, то стоит глянуть 7cart. Он на PHP7 и PostgreSQL11.
github.com/7cart/7cart
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Python vs PHP. Да начнется святая война.
Go!
Рекомендую PHP+Laravel+RDBMS(MySQL, PostgreSQL)
Python — плохая производительность, дорого, сложнее заменить разрабов, сложнее с хостингом.
Говорят, разработчики на питоне получают особое эстетическое удовольствие от программирования на этом языке... но вам то что? :)
Java — все очень хорошо, но и очень дорого + скорость разработки поменьше, чем на PHP
С#, ASP.NET — Все как у Java, есть некоторые преимущества платформы и языка, но они полностью нивелируются завязкой на продукты MS
Node.JS — быстро написать — ок, но вот поддерживать большую базу кода на JS — это ад (а проект у вас немаленький), не рекомендую
По PHP фреймворкам:
Symfony можно рассматривать, но на Laravel будет быстрее разработка.
Yii2 — можно рассматривать, прямой конкурент Laravel, я в свое время перешел на Laravel из-за слишком монолитной структуры Yii. Для меня Laravel выглядит немного прогрессивнее, но это ИМХО. В Laravel все-таки много разного рода кривостей, из-за которых хочется смотреть в сторону Symfony, но Symfony во многих аспектах «слишком академический», потому иногда хочется смотреть в сторону след. пункта:
Последний из актуальных вариантов: комбинация микрофреймворка(Slim,Silex) + Doctrine (можно только DBAL, можно с ORM) + шаблонизатор на свой вкус и отдельные компоненты Symfony под любые нужды. Так можно построить архитектуру, подходящую вашему проекту лучше чем то, что предлагает Laravel. Но это актуально только в случае наличия высококвалифицированного лида, да и принимая такое решение, будьте готовы, что придется писать много такого, что под Laravel уже есть в виде готовых высокоуровневых пакетов (админки из коробки, авторизация через соц-сети и все в таком духе).
Так что, Laravel.
Отдельно не рекомендую вестись на разного рода маркетинговый буллшит по поводу NoSQL. У этого типа технологий своя узкая ниша. Для проектов вашего типа идеально подходят классические RDBMS. С ними разработка будет сильно быстрее и проблем меньше.
как тут уже сказали, проще всего найти сначала людей которые будут делать, а они пусть уже решают. Пыха 7 намного быстрее питона. Симфони дороже будет стоить, проще взять Laravel для кастомного решения. Но, самый дешевый и быстрый вариант, взять wordpress под блог, и что то типа Magento, хотя может и OpenCart сойдет, та даже под wordpress есть приемлемые ecommerce решения. А там уже решить что будет основным, что на поддомене или вообще в папке. Свое решение писать долго, вылавлить баги, сапортить и тд. Хотя если много или денег или времени то можно и заморочиться.
1. если вы являетесь конечным потребителем, а не реализатором, разработчиком проекта (иначе, подобных бы вопросов не задавали б) выбирайте команду, а не платформу, так как именно команда будет обеспечивать основную итерацию в жизненном цикле данного софта — саппорт... изучив конкурирующие предложения и остановившись на конкретном реализаторе, доверьте этот выбор именно выбранной команде исполнителей
2. если вы — разработчик, личное имхо — когда вы не относитесь к нашему Богоиздранному народу Java-девелоперов ;) следует если не забывать, то минимум начинать интересоваться golang в качестве альтернатив семейству скриптовых, существующих и широко известных на данный момент (однако, против Node.js всё-равно ничего против не имею).
Из личного опыта — когда наш местный go-сектовод словил трип go-евангелизма и стал спимить им тут все топики, признаюсь честно — меня слегка выбешивало, однако, переведя за 1.5 месяцев два проекта с ларавела на GO, я стал платить за дэдик на $30 зелени меньше — не фонтан, но всё же... а если вы говорите о е-комерце, то перваночальные капиталовложения плюс капитализация рисков в случае масштабирования весьма важны.
Здесь, конкретную CMS рекомендовать не буду, мне под себя пришлось перепиливать много чего, но понравились эти: fragmenta.eu и ponzu
Кстати, JetBrains имеет уже давно имеет весьма адекватную IDE под это
3. если вы PHP-разработчик: юзайте вердпресс + (www.oscommerce.com | www.prestashop.com) и упаси вас от магенты, если что. Однако, единственное, имхо адекватное (но прожорливое как тысяца спрингов) — sylius.org (и на Богоугодной symfony)
а пайтон... лично я уже вообще не рассматриваю как что-то, замарочкой с чем следует уделять внимания... просто есть Go, который судя по всему его окончательно ликвидурует, так что, ИМХО, не тратьте на него времени.
Да ну ладно, серьезно, Go?
1) Будьте готовы к тому, что разработчики будут стоить в 3 раза больше чем, например, PHP и заменить их легко и быстро не получится в случае выхода из строя.
2) golang — язык простой как дверь и в виду этого, идеален для мелкого тулинга, но совершенно не подходит для больших проектов (платформа для блогов + eCommerse это в любом случае не мелкий проект)
1. А питон вот проще найти)))
2. Ну да, скажите проектам типа докер.
«Давно знаю одного веб-разработчика. Обалденные сайты клепает. Даже визитки с нулевым функционалом такие, что слюну пускаешь, когда разглядываешь. Но в один момент дядька перестал сайты делать. Я спросил, чего это он. Говорит, устал доказывать, что сайты за 100 $ — говно.» ©
Завидовать Лебедеву,- это все равно ,что завидовать, что не купил в 2012 году биткоины по 10 центов.)
Если хотите кастомного кода и CMS не подходят (скорее всего подходят вполне)
Наймите хотя бы нормального спеца что бы он вам базу данных нормально спроектировал под ваши статьи/блоги/товарные позиции и прочие хотелки это уже будет половина дела и хоть что-то правильно
Потом уже можно даже силами джунов++ что то собрать за пару месяцев/лет итд
Питон/РНР/Симфани/Руби уже на усмотрение разработчика которого сможете найти
На чем друзья-знакомые умеют я бы и остановился бы
Супер екзонтику не советую — будет дороже и сложнее найти спеца как писали ниже/выше
Я бы посоветовал РНР и тот же Laravel (сугубо от того что умею его готовить и любой проект вижу в нем),
но в итоге вам скорее всего сляпают фрилансеры на wordpress-ике что-то за недорого и по быстрому )
Если так — то разнесити хотя бы на один вордпресс обзоры / на другой магазин(товары) может хоть чуть быстрее будет все работать если всего так прямо по десятки тысяч в день
спасибо за совет.
разнести на два сайта — это сделать два домена? один с текстом, другой с товарами по ссылкам из текста?
два инстала CMS (разные базы/юзеры/админки)
можно делать как shop.site.com & site.com
так и в папках site.com & site.com/shop
там еще и + с стороны SEO есть (когда субдомены)
интересная идея. спасибо.
подумаю как можно в такОм разрезе реализовать саму идею.
возможно, для пользователей разницы не будет никакой. будут простые привычные переходы со страницу на страницу.
Это не «идея», а единственный вменяемый вариант. Так делают не только лишь все. Думать там не о чем, просто сделать и всё.
разнести на два сайта — это сделать два домена?
Это сделать ПОДдомен. Покупать надо только сам домен, а поддомены вы ему сами прописываете. Уже на самом сервере их или на Nginx или на Apache разнесёте. Рекомендую nginx+Апач, поскольку апач лучше защищён, а нжинкс быстрее отдаёт статик-контент (картинки, стили, скрипты и прочих хлам).
Апач уже давно не нужен от слова совсем (если мы о PHP стеке) php-fpm и вперед
Не факт. Я бы не сказал что он чем-то мешает. По крайней мере на нём много проще поддерживать права доступа к папкам, переписывать заголовки, и прочие костыли костылячить.
Так что на этапе поднятия очень рекомендовал бы именно апачину. Когда будет реальный хай-лоад (чаще всего никогда) — тогда и думать.
По крайней мере на нём много проще поддерживать права доступа к папкам
What? а можно поподробнее?
И всё равно через жопу, в смысле через грёбаные конфиги — с неочевидным синтаксисом, ещё менее очевидными ошибками, настройками через грёбаную магию RegExp — кто б сказал на кой хер это нужно?
Назвался Апликейшен сервером — давай функционал. А нет — идёт к Эскобару, была печаль на продакшене поделки тестить, когда всё на индейцах давно пашет.
Почему именно эти два варианта? Почему не Node.js или Go?
(Просто интересно понять мотивацию.)
потому что эти были предложены и обсуждались.
Node.js и Go не обсуждались. Вот и всё.
Изначально всё шло от выбора: взять коробочное решение или писать с нуля. Была предложена Симфони для написания с нуля, вместо шаблона на ВПресс.
Смущают сроки, стоимость и ранее неизвестный мне фреймверк — в плане дальнейшегоразвития и поддержки. Ну и — стабильности работы.
Правильно ли я понял, что у вас большой блог (много статей) + магазин?
Я думаю, что стоит исходить из таких параметров баланса таких характеристик как: нагрузка, на которую вы расчитываете, время, за которое вы хотите запуститься, и бюджет на команду (и возможность её подбора).
Если вы хотите быстро запуститься, то (учитывая что это блог и магазин) вам лучше использовать вордпресс, т.к. людей работающих с ним очень много. При этом когда через год-два к вам придёт миллион пользователей, вам будет больно, и придётся переписывать и/или серьёзно оптимизировать, но зато эти пользователи будут через год, потому что ваш проект будет работать уже сейчас.
Если вы хотите потратить чуть больше времени и сделать сразу сравнительно хорошо, то я бы советовал выбирать между РНР фреймворком и Node.js, потому что много программистов и много библиотек. Симфони — мощный фреймворк, но тяжёлый, это надо учитывать, если надо производительность. Плюс не все программисты его знают. Ларавел тоже жрёт кучу памяти, т.к. основан на Симфони, но разрабов к нему больше, как мне кажется. Для блога неплохим вариантом является CakePHP.
Это довольно субъективное и спорное мнение, но питон, мне кажется что его нет смысла использовать в вебе вообще нигде. Он не даст преимущества ни по производительности, ни по количеству (и цене) разработчиков.
Если же вы хотите сделать так чтобы было прям сразу быстро, производительно и масштабируемо, то лучше Go ничего не найти. Завтра вам понадобится подключить 20 серверов, чтобы обслужить миллион пользователей, и вы сможете это практически без проблем. Но разработка скорее всего обойдётся чуть дороже, что-то, особенно относящееся к сео, придётся делать руками.
Если вдруг захотите делать последний вариант, можете мне написать. ;)
Положа руку на серцо — вы бы сами выбрали «это» при том что кодить нужно будет нанятым с рынка спецам за ваши деньги?
если петпродект и сам фанат нод/го то не вопрос — но человеку такие технологие не нужны 100500%
прям слово в слово хотел то же самое написать))) одно дело в новомодные свистопеделки играться, другое дело бизнес))
одно дело в новомодные свистопеделки играться, другое дело бизнес))
а третье дело — бизнес на новомодных свистоперделках))
По факту наличия велосипедов на рынке, и мастеров/контор которые их ремонтируют и дорабатывают напильником.
Или лучше делать с использованием Python?
или с использованием Ruby on Rails. Или с ASP.NET’ом. Или еще с какой-то кошерной технологией)
А вообще — бери то, что лучше знаешь — и пили на нем)
Хорошо знаешь Symphony? Вперед! Ну или Laravel, если симфони знаешь не нрастолько хорошо, как хотелось бы (ларавел вроде легче симфони в освоении, да и популярнее) — на ларавеле, например, написана October CMS — берешь ее и допиливаешь на ларавеле нужный функционал. Это если ты пхп знаешь лучше, чем другие языки программирования, применяемые в веб-разработке.
з.ы. если в программировании не силен, то просто ищешь тех людей, которые смогут реализовать тебе нужный функционал на каком-нить языке (главное, чтобы это было потом кому поддерживать и развивать, поэтому желательно выбрать что-нить популярное, или набирающее популярность).
есть такое предложение. немного не то выходит. но на первое время (год...) можно попробовать совместить, немного переназвав разделы и используя их не совсем по назначению.
Нет ничего более постоянного, чем временное.
возможно. так часто и бывает.
хотя для МВП — подходящий вариант.
Если вы не специалист в области разработки то лучше выберите PHP. Для поддержки потом намного проще найти разработчиков (100 баксов — пачка). Симфони не для таких решений. Лучше использовать Yii2 или Laravel, но можно и специализированную CMS типа Опенкарт, в зависимости от фукционала.
Спасибо. Как я понимаю, Симфони тоже на РНР.
Почему оно не для таких решений тогда?
Да PHP, но главное предназначение симфони писать большие корпоративные приложения со сложной бизнес логикой, группой разработчиков. Симфони имеет ряд архитектурных особенностей, которые для вашего сайта откровенно не нужны. Поэтому разработка на симфони долгая, дорогая и специалистов относительно мало и соответственно они тоже дорогие.
Такой проект реально реализовать на Yii или Laravel но в CMS много функционала народ пишет долго и упорно поэтому «быстренько с нуля» не получится.
Быстренько — это сколько? На Симфони говорят о сроках в
скорее всего уже у них своя готовая СМS на симфони, заточенная специально под интернет магазины.
А может у них подход взять готовое натянуть на новый шаблон и втюхать подороже не в никач в специфику бизнеса особенности и необходимости и дальнейшее развитие проекта пофиг
хотят впарить существующий велосипед, только перекрасить шаблон и подставить пару костылей.
У меня есть сильное ощущение, что это удивительным образом гармонирует с предполагаемой бизнес-моделью будущего проекта...
может быть.
мне не так принципиально — новый или старый этот велосипед, как работающая платформа для контента и принятия заказов.
По-моему, на наших глазах родился новый мем — «сайт с блогами» ))))
да, звучит коряво :)
мне нужен блог со встроенным инет-магазином. стандартная ЦМС, по словам тех, кто пишет сайты, не вытянет функционал.
по словам тех, кто пишет сайты
по словам тех, кто хочет денег за написание сайтов. Особенно там, где CMS справляется.
За то что CMSки допиливают не сказал только ленивый. Это правильный путь. Тем более что допил обычно стандартный функционал не портит, это добавление нового модуля или нескольких.
А что такое блог с магазином — понятно не совсем. В чём проблема с блога просто давать ссылку? Пойми, когда хотят купить — просматривают много простых страниц, а не читают блог по каждой. Это разные этапы продаж, формулу AIDA не переделаешь.
можно и ссылку.
тогда будет куча длинных ссылок, что не воспринимается позитивно.
текст и картинка сбоку — я считаю, что будет нагляднее.
ссылку по слову никто не отменяет при этом.
То есть нужен плагин, который по ключевым словам блога будет подбрасывать товар из магазина в определённое место блога на WordPress/Drupal/etc? Звучит как ТЗ.
Делать на том, на чём CMS блога написана. То есть вероятнее всего на PHP. Ну и разумеется поискать может уже кто-то это делал. Искать лучше на английском.
приблизительно так. подтягивать предложение под слова.
вторым (или даже первым, потому что ранее всего обсуждался) был вариант WP+WooCommerce с кучей плагинов, чтобы подогнать под то, что нужно.
благо на Западе методы продаж чуть дальше шагнули и есть уже технические решения похожие на нужные.
подтягивать предложение под слова.
Рукалицо. Делайте на ВП — оно совершенно точно не взлетит, так хоть денег и времени потеряете немного.
А лучше посмотрите буржуйские топы, как люди делают. Никто не «подтягивает предложение» под непонятно кем, как и о чем написанный текст. Все с точностью наоборот — под конкретные, заранее отобранные офферы пишутся длинные-предлинные простыни текста (как, правило, обзоры/сравнения). Дальше уже кто во что горазд — кто свое продает, кто на амазоны всякие сливает. Но формат примерно тот же чуть менее, чем всегда: текст пишется под офферы, а не оферы «вытаскиваются» под текст.
Вы, конечно, можете попробовать изобрести свой велосипед. Но конверсия там будет стремиться к нулю по кельвину. «Запомните этот твит»
и да, и нет.
с маркетинговой точки зрения мне нужно положить вначале мысль в голову покупателю, сделать ему эмоцию в мозгах. и тут же предложить нужный товар.
а с технической — да, вначале я знаю что я хочу продать, а потом подтягиваю к этому «самое привлекательное предложение с текстом и видео о получаемом счастье»
Почему это на ВордПрессе блог не взлетит? Весь мир не прав, да?
Не блог не взлетит, а продажа случайных (программно отобранных) товаров или услуг с непонятно кем и для чего написанных текстов.
Так селекция будет в обеих направлениях. Автор ведь тоже будет писать про что скажут, не про унитазы.
Я понимаю, что имея дохера ресурсов (особенно человеческих) можно сделать намного круче. Кабы я была царицей...
Я написал, что нужно сделать — посмотреть буржуйские топы по запросам типа «best [gadget] 2017» и т.п. — чуть ли не наполовину это будут обзорники под офферы амазона или других партнерок. Там будет видно, насколько текст заточен под конкретный набор офферов (очень сильно). И даже на таком «таргетированном» тексте (написанном проф. райтерами по как правило достаточно жестким ТЗ) конверсия не превышает 10%. На никакущих текстах с полу-случайными офферами эту цифру можно смело делить на 20 — и это будет еще очень оптимистичным прогнозом...
В общем, ТС виднее конечно, что он хочет получить в результате. Но то что читается между строк выглядит стремновато. Хотя, вполне может быть, что я просто не въехал в затею.
интересная инфо.
у меня к прочему идет привязка к офф.лайну и личному общению человека с человеком. а инет-магазин + инфо = как помощь, и дополнительное развлечение.
Слишком огромна вероятность промаха. Так устроены в основном лохотроны, и только изредка — магазины товаров для очень богатых (они как правило тоже лохотроны внутри, но красивше)
не случайно отобранный. а промо-предложений в подборку к текущим заказам офф.лайна.
тексты — от тех, кто профессионально их пишет для читателей.
Это ошибка. Исключение — если этот писатель работает у вас, или вами нанят по личному знакомству. Иначе вам быстро напишут красивого текста, который ничего не продаёт.
Практически все амбициозные менеджеры на это нарываются. Только некоторые [немногие] потом осознают ошибку и всё переписывают. А большинство наоборот, готовы до потери пульса [у компании] защищать свою «гениальность», лишь бы не признать что потратили какую-то сумму впустую.
мне не нужны амбиции. я своими деньгами рискую.
авторы — свои и по рекомендациям.
тут бы два сайта в принципе работали вместе и не разваливались.
С чего бы им развалиться? Взял велосипед и поехал, а красивости уже по ходу довешиваешь.
Не понравился велик — делаешь соседний на поддомене, вылизываешь, тестишь, а потом экспортируешь товар и поехали. То есть сначала ехать, потом шашечки.
блог — легко. мне нужно связать с продажами его.
возможно, что два сайта завязанных друг на друге — решение вопроса.
текст на одном с ссылками на товар на другом.
идин сайт.
изначально думал только о таком.
Ну вы же не используете болгарку одновременно для резки металла и для мойки машины. И не пытаетесь найти водонапорный агрегат, который бы заодно и металл резал. Так откуда надежда найти один фреймворк под две в корне разные задачи?
Всё что по сути нужно — два разных комплекта кода, положенных в соседние папочки на сервере и вероятно смотрящих на одну базу. Вот и вся сказка. Скрещивать ежа с обезьяной не нужно, просто «познакомить».
Реально думать о том чтобы сделать что-то очень крутое будете когда у вас оборот за тысячу покупок в день перевалит. И даже тогда вероятнее всего откажетесь, поскольку эксперимент покажет фиаско.
Блог полностью отойдёт SMM менеджеру, и даже люди ведущие магазин и блог будут общаться раз в понедельник.
может и так.
оба они — вспомогательные технари.
основная работа — лицо.в.лицо с покупателем.
Да ну конечно. SMM — гуманитарий! А ведущий магаза — товаровед и саппорт, то есть административная (не интеллектуальная) деятельность. Оба дешевле чем технари.
Тебе ведь надо что покупатель пришёл с горящими глазами и криком «хочу щичас!», а не в наручниках и с пистолетом у виска.
я имею в виду их вспомогательную функцию в продажах.
базовая — у продавца, который лицом к лицу общается.
у технарей, которые пишут сайт и поддерживают его, — так же вспомогательная функция.
базовая — у продавца, который лицом к лицу общается.
Это большая ошибка. В онлайн-торговле мяч всегда на стороне покупателя. Не буду рассказывать всё что знаю, всё равно не поверите, что театр начинается с вешалки. У вас есть ровно нулевой шанс пообщаться с покупателем, который убежал на более ранних этапах конверсии.
Ну собственно, это и надо сделать. Дополнительно в самих статьях жёстко линковать на магазин. Вот и вся задача. Никаких «MVP» — это ж не инновация, а тривиальный шоп-проектик. Взлетать он не умеет в принципе, он должен плавать.
Было бы странно услышать другую точку зрения от питонщика
while($Butthurt->level>0){recursion();}
писал и на питоне, и на пыхе, если бы я выбирал для своего бизнеса — то выбрал бы пыху. Во первых, питон нефига не проще сапортить. Во вторых семерка делает питон по скорости в несколько раз, а для сайта у которого много посещений каждая секунда дорога. Про «дороже» и «уровнем ниже» поржал.
А если на Питоне с использованием aiohttp + uvloop?
Drupal 8. Но нужно хорошо разобраться в требованиях и возможностях CMS.
Для блога не шибко и нужно, там всё буквально из коробки. А вот магазин на него натягивать — гемор редскотстный.
Ну я ж говорю, нужно в друпале разбираться. Если есть знание существующих модулей, то сделать магазин можно просто. Блог делается из коробки, через views ии встроенный модуль для блогов.
НЕ просто. Друпал крайне непрост, точно говорю. Даже «через жопу» не в полной мере описывает его структуру.
Вот представьте себе проститутку, у которой внутри пирсинг из рыболовных крючков. Каждый кто её трахал до этого, добавлял свои крючки для будущих поколений. Примерно это и представляет собой попытка реализовать на Друпале что-то, что ему не свойственно совсем ни разу.
Зато наследуются все проблемы популярности платформы в плане безопасности. То есть обновлять её надо много и часто, и каждая следующая версия обязательно порадует багами, которые разумеется ни одним тестом не ловятся.
Под магазин надо ставить отдельную платформу. Без вариантов.
Описано красноречиво :).В этом есть доля правды, но все таки популярносто просто так не появляется. Необходимость этих крючков обусловлена универсальностью. Но с другой стороны нужно хорошо разбираттся в архитектуре построения программного обеспечения чтобы велосипед получился хороший. Ну или же конечно использовать спец софт под магазин, но я не знаю хорошего бесплатного.
Открытка — это все доказательства что получилось привести против использования Drupal ? :)
Понимаешь, то что ты описал — и есть CMS. Content Management System.
Так что вопрос исключительно в выборе CMS. Сам с нуля ты ничего конкурентоспособного собрать не сможешь — это долго и геморойно. А вот взять готовое с халявной или недорогой лицензией и допилить модули под свои нужды — это то что делают не только лишь все.
Блог и магазин стоит разделить. Отдельно выбрать CMS под блог, а то и вовсе расположить его на халявных сервисах (это может отразиться на SEO, и ещё вопрос в какую сторону). Отдельно поднимать магазин.
В Украине в виду не особой любви к рашке, у нежелающих учить англицкий популярен местный продукт. Я не сторонник, но любителей именно его — овер дохера.
в том же и вопрос, что мне нужно подать информацию (текст) с возможностью купить товар на одном экране. с сылкой на слове или рядом стоящей картинкой... но одновременно.
На Python жаліються, що важко шукати людей і вони дорого обходяться.
на symfony тоже не просто найти, хотя наверное полегче, чем на python
Стоит ли использовать PHP или Python для интернет-проекта? CMS не подходит
Стоит использовать педали (алюминиевые) или спицы для транспорт-проекта? Велосипед не подходит.
Ездить надо сотни раз в неделю. Десятки километров, и мигать задним фонариком.
Valentyn K
Dmytro Kokoriev
Smart Live
Roman Hanin
Alex Za
Vladimir Chernetsov
Alex Fogol
Vitalii
Alex Bylim
anonymous
Vitalii
Bohdan Pomazan
Sergey Sheshenya
Олексій Пєніє
Sergey Sheshenya
Andrey Tkachenko
Andrey Tkachenko
Yuriy Dyachuk
Evgenii Vorobey
Iliya Isd
Iliya Isd
Oleksii Pavlov
minodvesP Vasya
minodvesP Vasya
Artyom Krivokrisenko
Dmitry Zozulya
Dmitry Zozulya
Александр Шевченко
Sasha Potienko
Sasha Potienko
Aleksey Kolupaev
Nikolay Mihalych
Konstantin Strukov
Alex Bylim
Shanya Dmitry
Dima
Dima
Олексій Пєніє
Ihor Gorobets
Lenur
99 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів