Пишу свои мысли о web-разработке и о жизни. Работаю в веб-студии Феникс — phoenix-cg.ru Связаться со мной можно по почте viktor@koreysha.ru

Most commented over the month

Ищу начинающего дизайнера

Mar 30, 2017, 11:52

Друзья, нам в студии «Феникс» не хватает рабочих рук. Ищем начинающего дизайнера в Екатеринбурге.

Кто мы такие

Мы делаем сайты, а так же ЦРМ, ЕРПи и другие системы автоматизации процессов на веб-технологиях. Работаем в офисе в центре Екатеринбурга. Наши клиенты — крупные застройщики, интернет-магазины и все, для кого сайт может стать «верхушкой айсберга» от которого мы будет растить, невидимые во вне, системы автоматизации внутрь компании.
Мы стараемся улучшать все наши проекты не только из наших мыслей и мыслей клиента, но и основываясь на статистике.

Кто нам нужен

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

Минимальные системные требования:

  • Умение работать хотя бы с одним графическим редактором. Нам будет проще, если это Фотошоп.
  • Иметь в портфолио один-два веб-проекта, о которых вы сможете рассказать.
  • Желание и возможность работать.

Если вы подходите под это описание, то пишите мне
на почту koreysha@phoenix-cg.ru
или в Телеграм @koreysha

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

Сколько человек делают сайт: продолжение

Jul 4, 2016, 14:27

Писал как-то полу-шуточную заметку о том сколько программистов оптимально для проекта. Оказывается не меня одного волнует эта тема. Вот вариант ответа на этот вопрос от commitstrip.com

Почему клиенты любят CMS?

Dec 6, 2015, 21:50

CMS — инструмент разработчика. Вообще, надо сказать, что любой сайт, который возможно как-то администрировать, включает в себя компонент управления содержанием сайта. То есть любой такой сайт содержит в себе компонент CMS. Однако, часто люди далекие от кода, да, чего уж врать, бывает и сами разработчики, понимают под этой аббревиатурой другое понятие.

Часто я слышу от клиентов такие слова, как «движок», «ядро», «Цеэмэска». Как правило под всем этим подразумевается некая web-система, которую можно поставить платно либо бесплатно и которая уже сделала за программиста половину его работы. Обратите внимание, для многих клиентов сайт делает программист. На самом деле, конечно в процессе создания сайт может участвовать множество людей, часть из которых  — разработчики. Это дизайнеры, верстальщики, фронт- и бекенд программисты и все, кто создает сайт и хочет называть себя разработчиком. Такое понимание, конечно же, в корне не верное.

Начну с того, что тут не так. С точки зрения разработчика, как я уже отмечал, CMS система — одна из компонент проекта. При этом, далеко не всегда это «основа». «Ядром», или лучше сказать основной разработки, может послужить фраемворк, может совокупность отдельных готовых модулей. Это может быть даже одна отдельно взятая библиотека или же такой основы может вовсе не быть. Все это должно волновать заказчика в последнюю очередь, так же, как и стул, на котором сидит дизайнер или текстовый редактор, которым пользуется менеджер проекта. Все это — внутренние вопросы, которые помогают или мешают исполнителям решать проблему заказчика.

Так почему же заказчики часто настаивают на использовании готовых многофункциональных CMS систем? Существует несколько причин. Разберу основные.

Экономия

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

Страх выбора плохого разработчика

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

Опыт работы

Часто заказчики говорят, что уже имели дело с сайтами на какой-то CMS системе и, так как их все устраивает, не хотели бы её менять. Пожалуй, это самая существенная причина из всего списка. Конечно, если имеется ввиду, что со стороны клиента есть штат людей, обученных администрировать сайты на какой-то платформе. В этом пункте замечу только, что обычно даже у очень сложных сайтов механизмы администрирования достаточно просты и люди переучиваются за 2-3 дня. Ну, конечно, исключая какие-то особые случаи.

Функциональность будущего сайта

Тут многие клиенты слышали о какой-то функциональности той или иной CMS и хотят сайт «на ней», что бы было так же. Хочу сказать, что этот пункт, на самом деле, полностью эквивалентен первому. Если что-то разработчикам проще взять готовое, то они и так могут это сделать. А если не делают, значит для них это не проще. И в любом случае, этот никак не влияет на проект в целом. Любой функционал можно повторить. Иногда сделать заново проще, чем переделать. Но тут уже ловушка для самих разработчиков. О ней я постараюсь написать позже.

Откуда ноги ростут

В заключение, хочу сказать, что у нас в стране, «балом» правит одна известная всем компания. Она захватила бухгалтерский рынок и успешно конкурирует на рынке платных CMS. Именно они распространяют все эти мифы. А связано это с тем, что маркетологи этой компании в какой-то момент поняли, что деньги платят не программисты, не дизайнеры и не директора веб-студий, а клиенты. И направили весь свой маркетинговый арсенал на представителей малого и среднего бизнеса. Конечно, что-то им пришлось исказить ли приукрасить по тому, что это ужасно противоестественная ситуация. Ну не может клиент выбирать инструменты разработки — это не его компетенция.
Маркетологам этой компании аплодирую стоя.

P.S. Для тех, кто не знает о ком я, посмотрите рейтинг CMS рунета. На картинке рейтинг платных CMS по версии iTrack.

Первый опыт дизайна

Nov 21, 2015, 22:03

В конце сентября учавствовал в конкурсе на переверстку плаката. Итоговый плакат получился ниже среднего, если не сказать жестче. Тем не менее, для себя я результат считаю положительным, по тому, что основной задачей была «проба пера». О процессе я создал отдельную страничку. А результат могу продублировать тут:

Если кому-то интересно, то вот результаты.

Мой первый раз с WordPress

Nov 20, 2015, 16:50

За три года, что я работаю в web-разработке мне как-то удавалось избегать самого популярного в мире движка, не считая совсем мелких правок. Но мне приходилось слышать от коллег различные мнения от «Какое извращение превращать блог в магазин, форум и все, что угодно!» до «Вполне адекватная CMS для небольших проектов.» И вот предоставилась возможность поработать с WordPress воочию.

Первый блин

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

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

В переносе мультисайта мне помогли заметки SiteHint.ru и  WP MAGAZINE. Как я понял, сложности связанные с этим давно известны сообществу WP и обсуждать их смысла нет. Наверное, этой заметки бы не было, если бы сайт «завелся» сразу после этого без проблем.

Настоящее веселье

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

«Плавали, знаем», подумал я и стал искать, как включить ошибки. Перепробовал все, что можно от включения в конфиге, путем определения констант:

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

до прямых директив

ini_set('log_errors','On');
ini_set('display_errors','Off');
ini_set('error_reporting', E_ALL );

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

update_meta_cache('post', $post_ids);

А в ней проблема возникает во время запроса кэша из БД:

$meta_list = $wpdb->get_results( «SELECT $column, meta_key, meta_value FROM $table WHERE $column IN ($id_list) ORDER BY $id_column ASC», ARRAY_A );

И, наконец, изучив объект $wpdb я нашел место падения

while ( $row = @mysqli_fetch_object( $this->result ) ) {
$this->last_result[$num_rows] = $row;
$num_rows++;
}

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

Решение

Убрав собачку я увидел уже истинную причину проблем:

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 81 bytes) in /var/www/path_to_script/wp-db.php on line 1684

Временно забыть о проблеме с памятью удалось заменив в wp-config.php

define('WP_MEMORY_LIMIT', '64M');

На

define('WP_MEMORY_LIMIT', '128M');

Конечно, нужно искать причину, почему скрипт «жрет» столько оперативки, но это уже не срочно.

Как так

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

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

P.S. Все вышесказанное о движке WordPress 4.1.8