• Смотрят ли на корочку в IT?

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

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

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

    Отметки играют роль в процессе учёбы - гранты, стипендии, стажировки и т.п. Цвет диплома может сыграть роль в очень редких случаях.

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

    P.S. В целом если вы учились для знаний, а не для корочки, то любой ваш собеседник почувствует это без вопросов о дипломе и вам как айтишнику строить карьеру будет сильно проще.
    Ответ написан
    Комментировать
  • Где можно скачать самую большую MySQL англоязычную БД городов мира?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    GEO NAMES каждый город содержит официальное английское название + неофициальные варианты транскрипции + официальное название на местном языке + куча другой полезной информации.
    имеет около 100 источников, постоянно корректируется. Содержит города с населением от 1000 человек.
    Ответ написан
    Комментировать
  • Что не так с begin() end() в виджете?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    <?= foo?> Это тоже самое что <? echo foo ?>
    вам видимо надо убрать знак равно после вопроса
    Ответ написан
    2 комментария
  • Падают демоны на PHP (Apache + Nginx), в чем причина?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    Тут видимо logrotate говорит апачу пора рестартиться и он исполняет.
    Ответ написан
    4 комментария
  • Какой Web API попробовать?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    Комментировать
  • Как увеличить скорость выполнения SQL запроса?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    Найдите способ добавить в WHERE условие которое ограничит множество product_shop.id_product тем которое сейчас входит в LIMIT.

    Т.е. этот запрос валят строки
    ORDER BY `sale` DESC
    LIMIT 0, 100;
    над ними и парьтесь.
    Ответ написан
  • Кто стащил деньги Скрилл или Альфа-банк?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    Около 25$ в среднем стоит SWIFT перевод. То что вы сделали это не вывод, это международный перевод из одного банка в другой, то бишь SWIFT операция. Оплата комиссии могла быть снята как у отправителя так и получателя но сути это не меняет.
    Ответ написан
    3 комментария
  • На чем сделать поиск?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    Тут нет заумного поиска, просто будет обычный списочный контент + SQL запрос с двумя параметрами и двумя диапазонами для фильтра. Пишете на том что более понятно, т.к. объём знаний о том как работает любая цмс, он явно выше этой простой задачи.
    Ответ написан
    Комментировать
  • Понятет ли Intel® HD Graphics 4600 монитор 4K?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    Может Max Resolution DisplayPort*/HDMI- 3840x2160@ 60Hz, 4096x2304@24Hz, VGA

    но вам надо проверить версию hdmi порта, должна быть не ниже 1.4

    через DVI не получиться но максимум 2560 × 1600, переходник это не лечит
    Ответ написан
    5 комментариев
  • Как правильно выстроить процесс разработки?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    sourcetree в последней версии глючен, в течении последних двух неделю отказались от него полностью.

    так и возьмите hg/git flow , будет ветка для продакшена (деплоется на боевой), для последних версий разработки develop ветка, которая деплоется на test, ну и по ветке на каждую фичу которую каждый разработчик расзрабатывает на своём dev сервере, когда закончил закрывает ветку фичи и она сливается в develop ветку и автоматом разворачивается на test сервере. Когда на тестовом сервере видим, что то вменяемое дев ветка сливается в мастер и мастер деплоется на боевой сервер.

    гуглить hg/git flow
    Ответ написан
    Комментировать
  • Что изменилось за последнее время в российском IT?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    Всё как и раньше, деньги есть, людей нет. IT в целом в любой пожалуй самый стабильный сектор.

    Стало ещё менее выгодно держать толпу джуниоров вместо пары сеньёров. Но полагаю уже до конца лета, свежие аутсорс конторы выгребут джуниоров и начнут конкурировать с друг другом по з.п. и подтянут нижную планку ближе к европе.
    Ответ написан
    Комментировать
  • Запрет на join? Оптимизированная выборка из связи многие-ко-многим без join с параметрами из линкованных таблиц?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    Они так говорят, потому что:
    1) Если вы везде используете JOIN то на большом проекте у вас перестаёт работать кеш встроенный в БД, т.к. insert или update хотя бы в одну из таблиц участниц join сбросит кеш всего запроса, а на больших проектах изменения данных идут постоянным потоком.
    2) JOIN делает жётские связи на уровне данных, это хоронит возможность оптимизации на уровне архитектуры приложения. Когда таблицы не связанны внешними ключами и запросами то мы можем перенести любую таблицу, в другую БД оптимизированную для нужных типов запросов, написать например на Си отдельный сервис/демон для этих данных. При этом нам надо будет переписать только одну сущность в приложении. В случае с разрешёнными JOIN может выясниться что переписать надо вообще всё.
    3) Существует популярный подход переваривания больших нагрузок/данных это шардинг, т.е. раскидывание диапазонов данных по разным серверам, это когда первые 10 миллионов записей лежат на одном сервере а вторые на другом, join в этом случае сделать нельзя.
    4) Нормализация, полностью нормализованная БД самая медленна(т.к. куча JOIN, каждый из них это умножение двух матриц), но зато самая компактная, полностью не нормализованная БД самая быстрая (так как всё берём одним простым запросом), но очень жирная и неприемлемо сложная в работе.

    Ваш пример очень абстрактен, если про него ясно только, что данных очень много и не известно кто и в каких условиях будет с этим работать, но скорость ответа важна, а количество запросов будет большими. (Например это API к которому сторонние люди будут писать приложения и потенциально рекламировать эти приложения по ТВ)
    То например так:
    1) Запросом c JOIN скормить данные этих двух таблиц в поисковый индекс на sphinxsearch
    2) Делаем запрос с параметрами book.param = 1 AND author.param = 2 поисковому индексу сфинкса, он возвращает нам PK ID нужных сущностей
    3) Делаем SELECT * FROM t WHERE id in(1,2,3..N)

    Таким образом мы получаем сложную и тяжёлую фоновую индексацию, но очень быстрые и отъедающие крохи ресурсов сервера запросы в онлайне. Из минусов сильно усложняем архитектуру, а соответственно написание, отладка и поддержка кода становятся намного дольше, а количество людей которые могут это делать намного меньше, что в свою очередь является серьёзной проблемой но другого уровня.
    Ответ написан
    Комментировать
  • Насколько важно сейчас начинающему веб-разработчику разбираться в SQL досконально?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    Реализация ORM обычно такова, что это тот же SQL синтаксис только в виде объекта вызовов методов объектов.

    1. В простых случаях, что то типа: User::findAll()->where(['id'=>10])
      Это как бы прикольно, но тот же SQL: SELECT * FROM user WHERE id =10 не выглядит более сложным.
    2. Join, ORM как бы скрывает джойны:

      $UserCollection = User::findAll()->where(['id'=>10]);
         foreach($UserCollection as $User){
            if($User->ProfileSetting->is_enable == 'yes'){
               doSomething($User);
            }
         }

      Тут как бы скрыто то, что запрос происходит к двум связанным таблицам (user и profile), это достаточно в многих случаях, но в любом случае это не круто, т.к. вы не знаете какой запрос или запросы генерит ORM и не понимаете, что происходит на самом деле.
    3. Внешний вид запросов в объектном представлении становиться тяжёлым для восприятия даже для запросов средней сложности, с SQL таких проблем нет.
    4. Для сложных запросов ORM не даёт ни чего, кроме варианта писать тот же SQL.


    ORM имеет серьёзные преимущества в кодогенерации, в написании автоматизированных тестов.

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

    Так происходит потому, что по мере роста вашей квалификации у вас будут пропадать сопутствующие задачи типа вёрстки и js, готовую архитектуру вам навяжут фреймворки, а вашей основной задачей будет манипуляции с небольшими блоками данных хранящимися в больших массивы данных.
    Ответ написан
    Комментировать
  • Ошибка в консоли, вызов функции?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    1) Проверьте область видимости функции playbtnclick, т.е. если после того как всё погрузилось набрать в консоле window.playbtnclick вывод покажет, что то вразумительное то с.м. пункт 2, если нет то подумать.
    2) Проверьте последовательность загрузки файлов и старта обработчиков
    Ответ написан
    Комментировать
  • Как правильно хранить json c кирилицей в MySQL?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    У вас слеши пропадают на уровне php, это видимо можно проверить прогнав str_replace('\\u','\\\\u',json_encode($data));

    Глюки на уровне Mysql можно прореветь переведя тип поля в которое пишется json в тип blob, если стало ок, то что то не так с кодировками в базе или соединении с ней.

    json_encode($massx,JSON_UNESCAPED_UNICODE); не решит проблему со слэшами, они используются не только для юникода
    string.gif

    Дополнено:

    слеш в строчках служит для написания непечатных/управляющих кодов в виде букв. Это не mysql это везде так. Например \t это не слеш + t (два символа), это один символ табуляции. так же и \u это не два символа а один, чёрт пойми какой.

    если вы сделаете insert into t set col = 'a\n\n\nb'; а потом select col from t; то вы уведите:
    a

    b
    т.е. три пустые строки межу a и b, если вы хотите сохранить само сочетание \n, то нужно писать insert into t set col = 'a\\n\\n\\nb'; Тогда при селекте будет a\n\n\nb, т.к. для того, что бы закодировать слеш в строке его нужно экранировать тем же слешем. Это нормально.
    Ответ написан
    3 комментария
  • Cowboy vs Nginx?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    Простите, а что общего вы нашли между ними?

    nginx - проксирует, балансирует, раздаёт, шифрует + куча приятных мелочей, + удобный конфиг, + куча тонких настроек.
    cowboy - лишь один из вариантов как послушать 80 порт на эрланге.
    Ответ написан
    Комментировать
  • Mysql выборка или cookie, оптимизация?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    Когда ваши цифры будут в 1000 раз больше и не будет денег на нормальный сервер, тогда ваша вопрос станет актуальным. При таких цифрах кеш не будет освобождать ресурсы сервера, они и так должны быть свободны, соответственно смысла в кеше нет.

    Если при таких цифрах у вас всё тормозит вам нужно, что то из: сменить архитектуру БД или разобраться как работать с БД или нанять админа.
    Ответ написан
    8 комментариев
  • Каких знаний php для верстальщика будет достаточно?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    Надо знать вот эти штуки: if, foreach, echo, <?=$var ?> - это всё. Остальное нюансы конкретного проекта вам разъяснит программист максимум за пол часа.
    Ответ написан
    Комментировать
  • Как продвигать фриланс биржу?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    Деньгами, тот же freelance.ru на старте платил партнёрам за каждого привлечённого заказчика(заказ), что то около 1000 рублей (10 лет назад) и делал это долго. Заказчики сами к вам не придут за них в какой то форме придётся платить.

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

    Обновлено:
    Lancer9: Если вас это улыбает, то вы делаете каталог заказов и исполнителей. Т.к. безопасные сделки и возвраты это костыль на фоне нормальных договорных отношений, соответственно выдвигая это как основные/единственные фишки вы теряете саму суть фриланса/биржи и их проблем.

    Вы могли бы ввести ЭЦП и перевести всех на нормальные договорные отношения и белую работу.
    Вы могли бы собеседовать исполнителей гарантируя их квалификацию.
    Вы могли бы в обязательном порядке составлять грамотные ТЗ для заказчиков.
    Вы могли бы конектить заказы и исполнителя через своего менеджера исключая ошибки выбора для заказчика и мониториг леты исполнителем.
    Вы могли бы делать лоукост биржу для джуниоров с гарантированным подключением вашего сеньёра в случае провала.
    И вы могли бы ещё кучу всего. Но нет, упор сделан на безопасные сделки и возвраты, но во первых вы не понимаете, что для нормально отстроенного процесса эти инструменты нужны только в случае форс-мажора, во вторых даже в этом случае "а судьи кто?", с высокой вероятностью заказчик или исполнитель могут иметь на порядок большую квалификацию чем судья, если бы вы это решали, вы бы об этом написали сразу.

    P.S. На комиссию плевать потому что её можно всю кинуть на исполнителя, а ему на неё плевать если за месяц после вычета комиссии вы генерируете больше денег чем другие биржи. Если эта сумма меньше то и нулевая комиссия не поможет.
    Ответ написан
  • В чем лучше хранить данные для быстрого доступа?

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

    Соответственно результаты будут состоять из двух запросов: простого селекта по уже агрегированным данным + сам агрегирующий запрос по суточной таблице.

    Т.е. если вы, каким либо способом, избавитесь от запросов по всему датасету в онлайне, то эта схема проработает у вас очень долго (до полного исчерпания аппаратных ресурсов) в независимости от того какую БД вы будете использовать.
    Ответ написан
    Комментировать