- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Нет, наверное ядро не пилят, но предварительно сказали, что уровень кастомизации будет такой, что автоматические обновления скорее всего будут невозможны и типа это нормально.
Но если потребуется обновление версии ядра, то это делается в ручном режиме с исправлением появляющихся косяков.
ну это действительно нормально, или ядро в ручную править, или все новые компоненты и модули, или и то и другое... без постоянной технической поддержки не обойтись)
ну будет у вас автоматическое обновление ядра, оно ж на самом деле не автоматическое, как минимум нужно кнопку нажать в админке, а потом понять что ново написанные главные компоненты и модули с обновленным ядром работать не хотят...
Это в теории хорошо. На практике...
На практике так. Сначала приходит один хрен и говорит, что все офигенно задокументировал, потом заболевает (уезжает в отпуск, начинаются семейные проблемы, геморрой, просто пропадает) , приходит другой хрен и говорит, что в этом коде хрен разберешься, прошу прощения за тавтологию.
На практике так. Сначала приходит один хрен и говорит, что все офигенно задокументировал, потом заболевает (уезжает в отпуск, начинаются семейные проблемы, геморрой, просто пропадает) , приходит другой хрен и говорит, что в этом коде хрен разберешься, прошу прощения за тафтологию.
Во во, причем тут хрен, и как он вообще говорить может? 😂
Wadim, tysson, господа, значит вам пока еще не удалось найти достойного исполнителя :( Но если код хреновый, то документированием его никак не спасти. Как только найдете - завязывайте контакт и работайте дальше с ним.
Да, есть проблема найти специалиста на небольшой бюджет. При определенной квалификации нет смысла работать ниже чем за 20$ в час. Для американского рынка это копейки, а в наших реалиях бюджет в рублях будет ощутимым при такой ставке.
Вот еще несколько критериев, которые, безусловно не являются панацеей, но способны уменьшить риски нарваться на дилетанта:
1. С большой осторожностью нужно относиться к предложениям написать все с нуля. Само по себе это не является чем-то плохим, но сильно снижает вероятность нарваться на не осилившего хоть один фреймворк, и при этом уверенного в своих силах, что у него с нуля уж точно взлетит.
2. С большой осторожностью относитесь к популярным CMS в случае их глубокой переделки. Дилетанты часто не могут осилить идеологически верный способ расширения функционала (например, написав плагин) и лезут править фирменный код по живому.
3. Среди готовых реализовать задачи используя фреймворк число специалистов выше, чем среди предлагающих решение на популярной CMS. Просто в силу порога вхождения.
4. Команда чаще более надежна, чем одиночка. Бывают и команды негодные, но среди одиночек процент дилетантов выше. Человек стремящийся к профессиональному росту стремиться попасть в хорошую команду - опыт в таком случае растет намного быстрее, чем у одиночек. Хорошая команда не будет держать откровенного профана - утопит всю команду. Ну и команда более стабильна, чем одиночка. Кто-то ушел, кто-то пришел, кто-то остался. Одиночка пропал - 100% потеря.
5. Попросите посмотреть кусочек кода. Пару десятков строк достаточно. Вы можете абсолютно ничего не понимать в нем. Это не важно. Просто посмотрите на названия - если видите что-то типа
zakaz_pokupatelya вместо customerOrder или куча малопонятных n1, m2 и прочего - лучше пройти мимо. Не бывает программистов, которые не владеют английским языком. Они были в СССР и сейчас уже на пенсии :). Вся фирменная документация пишется на английском. Хороший пример: авторы популярной IDE IDEA - россияне. Ее интерфейс и документация только на английском языке :) Т.е. если программист не владеет английским - 99% что он получает информацию из обрывков по форумам и, в лучшем случае, из переведенных древних книг. В которых часть информации уже устарела и не рекомендуется к использованию. Но они этого не узнают, пока не выйдет очередная книга лет через n или они, наконец, не выучат язык :) И оформление. Просто посмотрите, что-бы он было аккуратным. Если все криво-косо, куча комментированного кода неиспользуемого - проходите мимо. У специалиста код аккуратен. Комментариев минимум и все по делу. Профан же натащил копи пасты в код, на всякий случай. Поскольку решение дергал с нескольких форумов, а разобраться до конца не смог. И если одно "начнет ругаться", он раскомментирует другое :)
Wadim, tysson, господа, значит вам пока еще не удалось найти достойного исполнителя :( Но если код хреновый, то документированием его никак не спасти. Как только найдете - завязывайте контакт и работайте дальше с ним.
Да, есть проблема найти специалиста на небольшой бюджет. При определенной квалификации нет смысла работать ниже чем за 20$ в час. Для американского рынка это копейки, а в наших реалиях бюджет в рублях будет ощутимым при такой ставке.
Вот еще несколько критериев, которые, безусловно не являются панацеей, но способны уменьшить риски нарваться на дилетанта:
1. С большой осторожностью нужно относиться к предложениям написать все с нуля. Само по себе это не является чем-то плохим, но сильно снижает вероятность нарваться на не осилившего хоть один фреймворк, и при этом уверенного в своих силах, что у него с нуля уж точно взлетит.
2. С большой осторожностью относитесь к популярным CMS в случае их глубокой переделки. Дилетанты часто не могут осилить идеологически верный способ расширения функционала (например, написав плагин) и лезут править фирменный код по живому.
3. Среди готовых реализовать задачи используя фреймворк число специалистов выше, чем среди предлагающих решение на популярной CMS. Просто в силу порога вхождения.
4. Команда чаще более надежна, чем одиночка. Бывают и команды негодные, но среди одиночек процент дилетантов выше. Человек стремящийся к профессиональному росту стремиться попасть в хорошую команду - опыт в таком случае растет намного быстрее, чем у одиночек. Хорошая команда не будет держать откровенного профана - утопит всю команду. Ну и команда более стабильна, чем одиночка. Кто-то ушел, кто-то пришел, кто-то остался. Одиночка пропал - 100% потеря.
5. Попросите посмотреть кусочек кода. Пару десятков строк достаточно. Вы можете абсолютно ничего не понимать в нем. Это не важно. Просто посмотрите на названия - если видите что-то типа
zakaz_pokupatelya вместо customerOrder или куча малопонятных n1, m2 и прочего - лучше пройти мимо. Не бывает программистов, которые не владеют английским языком. Они были в СССР и сейчас уже на пенсии :). Вся фирменная документация пишется на английском. Хороший пример: авторы популярной IDE IDEA - россияне. Ее интерфейс и документация только на английском языке :) Т.е. если программист не владеет английским - 99% что он получает информацию из обрывков по форумам и, в лучшем случае, из переведенных древних книг. В которых часть информации уже устарела и не рекомендуется к использованию. Но они этого не узнают, пока не выйдет очередная книга лет через n или они, наконец, не выучат язык :) И оформление. Просто посмотрите, что-бы он было аккуратным. Если все криво-косо, куча комментированного кода неиспользуемого - проходите мимо. У специалиста код аккуратен. Комментариев минимум и все по делу. Профан же натащил копи пасты в код, на всякий случай. Поскольку решение дергал с нескольких форумов, а разобраться до конца не смог. И если одно "начнет ругаться", он раскомментирует другое :)
Низкий поклон за достойный труд!
Низкий поклон за достойный труд!
Пожалуйста! Буду рад, если эта информация поможет сберечь свои деньги и, что еще важнее, стабильность проекта и нервы.
Еще одно свойство специалиста вспомнилось. Как-то давно смотрел с ребенком одну из передач "Очевидное - Невероятное", в которой уважаемый Сергей Петрович Капица (вечная ему память), рассказывал о некоторых явлениях ядерной физики. Стоить заметить, что процессы, о которых шла речь, описываются достаточно сложным математическим аппаратом. У нас как-то почти вся группа ушла на пересдачу по одной из таких дисциплин, поскольку достойные оценки практически никто не осилил с первого раза. Так вот, Сергей Петрович настолько легко, понятно и увлекательно рассказывал о сложных вещах, что даже маленький ребенок смотрел с интересом. Конечно, понять как это работает без математике, увы, никак. Но что это, и зачем это, понял даже ребенок.
Сергей Петрович, безусловно талант и гений. Таких единицы. Но после просмотра той передачи, я окончательно убедился в том, что когда специалист в своей теме, как рыба в воде, он сможет понятно объяснить человеку суть этой темы. Без ненужных деталей, без терминологического понтовства, без фраз "ты этого не поймешь, это очень сложно". Найдет метафоры, аналогии и т.п. Причем рецепт универсальный, применим к любой сфере человеческой деятельности.
4) Идеальный вариант писать на php c нуля, но он минимум в пару раз дороже.
Даже не дороже :)
Но это еще зависит от лицензирования и от того, сколько сайтов у компании.
Дороже будет, если нужны исключительные права на код.
Остановился на конторе. делают тестовое задание на 50 часов работы. час работы 1600 руб. пока вопросов нет, комфортно.
Но если код хреновый, то документированием его никак не спасти.
Про хороший код все говорят, но никто его еще не видел.
С большой осторожностью нужно относиться к предложениям написать все с нуля.
С большой осторожностью относитесь к популярным CMS в случае их глубокой переделки.
Среди готовых реализовать задачи используя фреймворк число специалистов выше, чем среди предлагающих решение на популярной CMS.
Определитесь уж, а то у вас полное противоречие самому себе. Любое решение на фреймворке - это самопис. И вообще, любой фреймворк - это тоже самопис.
5. Попросите посмотреть кусочек кода. Пару десятков строк достаточно. Вы можете абсолютно ничего не понимать в нем. Это не важно. Просто посмотрите на названия - если видите что-то типа
zakaz_pokupatelya вместо customerOrder или куча малопонятных n1, m2 и прочего - лучше пройти мимо.
Не несите пургу. Если эта переменная или объект нужна (нужен) в пределах к примеру функции, то название m1 вполне подходит. Ровно с таким же успехом можно докопаться до граблей, мол они плохие, так как тут зубья не покрашены. Да и судить по десяткам строк кода - бред.
Не несите пургу. Если эта переменная или объект нужна (нужен) в пределах к примеру функции, то название m1 вполне подходит. Ровно с таким же успехом можно докопаться до граблей, мол они плохие, так как тут зубья не покрашены. Да и судить по десяткам строк кода - бред.
Ну m1 как бы уже наталкивает на мысль о том, что есть m2...
Для итераторов такие названия так же не выбирают. Переменные должны быть названы осмысленно, это упрощает читаемость кода в разы.
По десятку строк сложно определить качество кода, однако легко понять, каша ли в голове у исполнителя или все по полочкам.