Сейчас практически все системы клиент-серверные. При разработке Paint, наверное, действительно не обязательно знать сети. Но любой хороший питонист, пхп-шник, рубильник и сишник должен сети знать.
Потому что если в команде 5-10 человек, то их возможности выработки серьезного осязаемого результата сильно ограничены (если это не гении типа 37signals).
Речь о зоне влияния не на других людей, а на результат работы организации. Если вы пишете код, то зона влияния ограничена возможностями одного человека — малая. Если вы разрабатываете архитектуру (касается только крупных и средних компаний) или управляете другими людьми, то зона влияния у вас большая. Кстати, разрабатывать архитектуру тоже можно на разных уровнях детализации. Вообще, про детализацию Лебедев хорошо написал в параграфе про прогрессивный JPEG.
Вон возьмите Торвальдса. Он код не пишет. Он управляет сообществом и применяет патчи. А Аксенов, например, код пишет. И сравните масштаб результатов их деятельности. (Это я в очередной раз к тому, что каждому свое.)
Так вот если бы уважаемый mike1 хотя бы близко приближался по уровню к таким людям, как Аксенов или Сысоев, не было бы этой статьи. И было бы одно из двух: либо работа в крупной технологической компании (то, чего он хотел), либо свой бизнес. А тут кроме огромного самомнения, долгого и широкого опыта (мастерсва) и насмешливого отношения к работодателю я ничего не вижу.
Подчиненных может не быть, но зона влияния соответствует званию. Это, наверное, про всяких замполитов. Думаю, вы понимаете, какое у них влияние, и какой уровень масштаб деятельности. Кроме того, это определенно руководители. Отсутствие прямых подчиненных не значит, что человек не относится к руководящему составу.
Это вырожденный случай руководителя. И точно такой же пример есть и в software engineering — архитекторы и евангилисты. Масштаб их деятельности очень широк в крупных и просто широк в средних компаниях. А в мелких компаниях по профиту они равносильны сеньерам. И в любой нормальной компании кандидаты на такие позиции должны отлично знать все, что тут обсуждалось. И это подтверждали многие руководители в комментах выше. Не можешь нормально и доступно объяснить, как работает HTTP и HTTPS, как работает TCP/IP? Какой из тебя тогда архитектор или евангелист? Как ты будешь коллегам передавать объяснять свои наработки? Подчеркиваю, не обязательно все знать на зубок, но уметь объяснить сходу (== понимать) нужно. Это моя позиция.
P.S. Если на собеседовании человек действительно в теме, то на вопрос «Как работает HTTP» он спросит на каком уровне объяснять (1-е обязательное условие) и сможет объяснить на запрошенном уровне (это не ниже уровня TCP/IP, но чаще всего речь вообще только об уровне HTTP, т.е. на уровне интерфейса стека TCP/IP) — 2-е условие. А вот если начинается выпендреж про WM_*, то это как раз человек толком и не знает ничего (либо он пришел на собеседование повыпендриваться, что всегда влечет отказ).
Сама цель в моем понимании — это увеличение масштаба воздействия. И достигается она только через переход к руководству. Это как в армии: офицеры только руководят, они сами окопы не капают. При этом именно от их решений зависит буквально все в бою. Чем выше уровень, тем больше степень влияния вплоть до максимального. А чем выше степень влияния, тем интереснее и эффективнее работа конкретного человека.
Если вам не интересно работать на высоком уровне, будьте готовы к такой ситуации, как написано в топике и некоторых комментах. И ничего страшного в этом нет — каждому свое. Просто понимание такой ситуации — это уже неплохо. А поддержание мысли, что вы самый нужный и самый ценный, даже если этот опыт приносит не больше профита, чем (1,5*senoir), влечет к таким обидам и непониманию требований на собеседованиях.
Не вырывайте из контекста. Я сформулировал очень четко:
Увеличение масштаба проектов не имеет никакого значения, если собственная роль в проекте не меняется. Это не имеет отношения к персональному росту. Опыт, рост вширь — да, рост ввысь — нет.
Ваш комментарий выше, на который я отвечал, касался карьерного роста (т.е. становления себя в качестве руководителя). Именно в этом контексте сказано: «Увеличение масштаба проектов не имеет никакого значения [в отношении к карьерному росту]»
Но чего мне действительно хотелось бы, так это постараться донести понимание ситуации до вас.
Не потому что я тут такой умный разумный. Не умнее вас, наверное. А потому что смотрю на все со стороны. И имею собственный программерский опыт, в том числе и управленческий, чтобы делать какие-то подобные умозаключения.
Индивидуалист — это подход к работе, стиль работы. Это не значит, что вы работали один. Индивидуалист развивает себя, собственные программерские скилы. А командный игрок развивает команду, собственные скилы взаимодействия и использования других людей в работе, имея за счет этого рост вверх (а не вширь).
В этом ответе сжато изложено ваше отношение к работодателю, которое 100 % отслеживается во время собеседования любым адекватным собеседующим. Тоже самое написано в статье, только здесь оно сжато. Вы проходили интервью в серьезных компаниях и так и не поняли, что у них огромный опыт в том, что надо спрашивать, чтобы найти нужный им персонал. И они отлично справляются с этой задачей. Они находят нужных. А вы им не нужны. А вы задачу устроиться на работу в хорошей технологической компании проваливаете из раза в раз. И не желаете понять, почему так происходит. Наоборот, вы убеждаете себя, что сам такой хороший и нужные, а они глупы.
И я не говорю, что вам надо меняться. Если вообще говорить о советах, то выше есть много классных комментов — именно советов. Обоснованных. И проплюсованных. А я от советов воздержусь, в том числе и по причине разницы в возрасте и опыте. Но чего мне действительно хотелось бы, так это постараться донести понимание ситуации до вас. Хотя бы просто взгляд с другой стороны. Вы упорно смотрите с одного угла и не желаете понять тех, кто смотрит по-другому. Вы пытаете объяснить коллегам, что эти работодатели какие-то странные, ничего не понимают. И, как известно, когда все вокруг странные, то обычно проблема не во всех.
Если руководить нет не желания, ни способностей — значит плохой программист?
Подчеркиваю — это мои личные наблюдения и личное мнение. Отвечаю: скорее всего да. Наверное есть исключения. И очень важное замечание: руководить — не значит перестать писать код. Обычно как раз наоборот — хороший программист-руководитель продолжает писать код, но это уже код более высокого уровня (например, библиотеки, или опенсорс для души). Очень хочу, чтобы меня правильно поняли. Постарайтесь, пожалуйста: хороший программист естественным образом растет не столько вширь, сколько ввысь. С ростом опыта и знаний он начинает шефствовать над другими, более молодыми программистами. Он использует свой опыт эффективно — на всю команду, а не на себя лично. Т.е. он растет по карьерной лестнице. Либо как вариант, начинает преподавать.
И еще раз: да, исключения, есть. И в большинстве случаев это либо гении, либо что-то близкое к гению.
P.S. Хоть я и использую глупое относительное понятие «хороший программист», но думаю, что большинство читающих правильно поймут, о чем идет речь.
А увеличение масштабов проектов, в которых участвуешь?
Увеличение масштаба проектов не имеет никакого значения, если собственная роль в проекте не меняется. Это не имеет отношения к персональному росту. Опыт, рост вширь — да, рост ввысь — нет.
Ниже не советы, не критика, а просто собственные ощущения от прочтения статьи и комментов (кстати, на удивление много конкретных, грамотных и обоснованных комментариев по теме).
1. Не следует так гордиться своими слабостями. Исходя из того, что «везде» вы получили отказы, можно сделать вывод, что на собеседовании вы общаетесь в той же манере, в какой написана эта статья.
2. Есть две крайности по типам проектов: А) где все строится на элегантности архитектуры, Б) где все строится на усердии и количестве программистов. Разные продукты делаются по-разному, и требования к разработчикам там разные. В крупных интернет-компаниях делают большие продукты, где все держится не на количестве кода, а не его архитектуре. В то же время, например, в банковском секторе даже в самых крупных компаниях все держится на количестве и надежности кода, а не на архитектуре.
Вы думаете, что в состоянии эффективно работать в любой компании (об этом написано в статье). Это глубокое заблежние, и странно, что оно присуще человеку с вашим не только жизненным, но и профессиональныем опытом. Складывается стойкое впечатление, что вы все это время шли вперед и смотрели только под ноги, не оглядываясь ни назад, ни по сторонам. Моя мысль в том, что ваш опыт пригодится для решения лишьт части задач, которые попадают под пункт Б. А в мейнстриме в интернет-компаниях (мы же про python тут говорим, а не про c++ на сколько я понял) как раз сейчас популярен и нужен программист-А (Б и так хватает). И программистов, так же как и инструменты, зачастую выбирают под задачи.
3. Ваш начальный опыт вообще имеет малое значение для работодателя. Все, что было более 15 лет назад, уже не актуально. Это даже про C++ можно сказать, а про Python я вообще молчу. Так что козырять этим багажом особого смысла нет. Важно, на сколько вы умеете работать в современных условиях, а не сколько кода написали ранее.
4. Ну и важный момент про работу в команде. Вы — индивидуалист. Вы готовы все делать своими руками (из-за этого и не стали до сих пор руководителем). При работе в команде нужно попадать под шаблон команды. Нужно уметь излагаит и понимать других. Это очень хорошо проверячется на собеседовании. Исходя из отказов, опять же предположу, что ваше мышление и общение не стыкуется со стандартными шаблонами. А в больших компаниях большие команды, там нужны люди-компоненты, а не индивидуалисты. Зато там, где нужны именно индивидуалисты, вас брали сразу, видя готовность решать любые задачи (именно решать, при этом не важно как).
5. После 40 лет на мой взгляд хороший программист — это тот, кто руководит. Как то вырисовывается такая картина из жизненного опыта. Если взялись ранно (как вы), то к такому возрасту можно уже высоко вырасти. Если взялись поздно (это не про вас, но мне такие попадались), то извините, но хорошим программистом вам уже не стать.
И ценность руководства не в том, чтобы много денег платили, или в хваставстве, или в ничего неделании. Ценность в масштабе. Карьерный рост — это увеличение масштаба воздействия своей работой. Вы как на вертолете должны взлетать все выше и охватывать все больше, при этом с меньшей детализацией. Это рост. А изучение новых инструментов — это не рост. Это просто опыт, который рано или поздно обесценится в такой динамичной отрасли.
Меня тоже очень интересует поддержка из Linux (Ubuntu в частности). Это, к сожалению, при выборе ноутбука самая большая проблема. 15-дюймовая модель этого ноута имеет дисплей IPS, что резко выделяет его среди конкурентов. Так что если у кого-то поделится информацией по работе на нем Ubuntu, буду весьма признателен. Прежде всего интересует работа с видео (переключение адаптеров и какой из них работает по умолчанию, если переключение невозможно).
Активно пользуемся ПДД для доменов разных проектов нашей компании (порядка 10 доменов). В целом, конечно, вы молодцы. Но некоторые проблемы есть.
Самая острая для меня — это рассылки. Причем не массовые, которые прочно ассоциируются со спамом, а рассылки-уведомления для сотрудников компании (от которых сотрудники по понятным причинам не могут отписываться, ну и подписываться), чьи адреса находятся на разных доменах в одном аккаунте ПДД.
А. Отсутствие слать почту на разные домены с одного. Ну это реально проблема. Про это уже писали, думаю дополнительные комментарии излишни — все и так понятно: это реально важно и нужно. Т.е. хотя бы включать в рассылки пользователей всех доменов аккаунта, хотя лучше, конечно произвольные адреса.
Б. Отказ в приеме почты из-за подозрений на спам. Часто сталкиваемся с такой проблемой. Подчеркиваю, что шлются письма только на «своих». Некоторые типы писем (где меньше текста и больше цифр) проходят нормально, а некоторые сразу выбивают по всем аккаунтам-получателям SMTP-ошибку типа «try again later». Later, естественно, ничего не меняется. Пробовал решить проблему через саппорт, но получил стандартную отписку про спам. И как бы все — делай что хочешь… С одной стороны понимаю ваши проблемы в этом аспекте, с другой — не понимаю, как проблему решать самому. С gmail таких проблем не было. Да, письма могли попадать в спам, но сервер никогда не отказывался их принимать.
Кстати, речь про именно получение писем на ящики в ПДД, потому что для их отправки мы используем собственные серверы, которые «настроены» в SPF.
Кроме этого, нужно отметить, что регулярно что-то сбоит. Ну об этом вы сами отвечали выше, что, да — бывает. С этим, кстати, действительно можно жить. На гугле тоже сбои бывают, вот один был на той неделе (у нас несколько доменов пока остались гугле).
Дальше замечание про панель управления DNS. У меня один из доменов делегирован к вам. Панель управления ДНС ужасна. Сложно сказать, что в ней неудобно, потому что неудобно все. Когда там порядка 50 записей, включая DKIM и SPF (большие блоки), пользоваться таблицей очень тяжело. Отсутствие банальных сортировок и фильтраций осложняет работу. Очень жду улучшения юзабилити панели.
А может кто-нибудь подскажет хорошую простенькую хелп-декск/тикетную системудля организации сбора заявок по обслуживанию сайтов? Т.е. я хочу наладть процесс взаимодействия с внутренники заказчикаи в организации. У нас много людей, много проектов и один отдел разработки.
Наверное, основное отличии структур-списков от массивов с позиции использования — передеча их аргументом в функции. Очевидно, что массив передается по значению, а список (например, SplFixedArray) — по ссылке. Из-за этого они как минимум не взаимозаменяемы логически. И в зависимости от потребностей одна из двух структур (массив против списка) может быть удобнее.
Для каждой зоны должна существовать только одна запись SOA и она должна быть первая.
Первой она быть не обязана. Во-всяком случае, файл, в котором она не первая, прекрасно проходит проверку. Однако, все значения, указанные в SOA-записи, применяются только к тем записям, что следуют ниже нее. Т.е. практического смысла делать ее не первой нет. Тоже самое касается и директивы $TTL (полагаю, что и $ORIGIN, хотя и не проверял).
1. Правильно ли я понимаю, что правильным современным способом работы со Sphinx является SphinxQL? Т.е. при реализации нового проекта смотреть на API не смысла. Да и указание в мануале на то, что SphinxQL умеет все, что и API, но наоборот — неверно.
2. А где в мануале рассказывается про экранирование спецсинтаксиса в расширенном режиме запроса? Очевидно, что при вставке в запрос строк от пользователя, необходимо обеспечить некий уровень экранирования (в самом жестком режиме запретить все).
3. Какой клиент лучше всего использовать для работы со SphinxQL из PHP? mysqli?
Да, аутентификация в протоколе бы не помешала. Но и без нее жить можно. Самый простой способ ограничения доступа — на файрволе. Если нужно ограничить доступ со своих серверов, то делается все фильтрами по IP на ура. Если все-таки по какой-то причине нужна авторизация, то можно организовать ее через тоннели: вариант 1, по-проще — SSH, вариант 2, по-сложнее — VPN.
Вон возьмите Торвальдса. Он код не пишет. Он управляет сообществом и применяет патчи. А Аксенов, например, код пишет. И сравните масштаб результатов их деятельности. (Это я в очередной раз к тому, что каждому свое.)
Так вот если бы уважаемый mike1 хотя бы близко приближался по уровню к таким людям, как Аксенов или Сысоев, не было бы этой статьи. И было бы одно из двух: либо работа в крупной технологической компании (то, чего он хотел), либо свой бизнес. А тут кроме огромного самомнения, долгого и широкого опыта (мастерсва) и насмешливого отношения к работодателю я ничего не вижу.
Это вырожденный случай руководителя. И точно такой же пример есть и в software engineering — архитекторы и евангилисты. Масштаб их деятельности очень широк в крупных и просто широк в средних компаниях. А в мелких компаниях по профиту они равносильны сеньерам. И в любой нормальной компании кандидаты на такие позиции должны отлично знать все, что тут обсуждалось. И это подтверждали многие руководители в комментах выше. Не можешь нормально и доступно объяснить, как работает HTTP и HTTPS, как работает TCP/IP? Какой из тебя тогда архитектор или евангелист? Как ты будешь коллегам передавать объяснять свои наработки? Подчеркиваю, не обязательно все знать на зубок, но уметь объяснить сходу (== понимать) нужно. Это моя позиция.
P.S. Если на собеседовании человек действительно в теме, то на вопрос «Как работает HTTP» он спросит на каком уровне объяснять (1-е обязательное условие) и сможет объяснить на запрошенном уровне (это не ниже уровня TCP/IP, но чаще всего речь вообще только об уровне HTTP, т.е. на уровне интерфейса стека TCP/IP) — 2-е условие. А вот если начинается выпендреж про WM_*, то это как раз человек толком и не знает ничего (либо он пришел на собеседование повыпендриваться, что всегда влечет отказ).
Если вам не интересно работать на высоком уровне, будьте готовы к такой ситуации, как написано в топике и некоторых комментах. И ничего страшного в этом нет — каждому свое. Просто понимание такой ситуации — это уже неплохо. А поддержание мысли, что вы самый нужный и самый ценный, даже если этот опыт приносит не больше профита, чем (1,5*senoir), влечет к таким обидам и непониманию требований на собеседованиях.
Ваш комментарий выше, на который я отвечал, касался карьерного роста (т.е. становления себя в качестве руководителя). Именно в этом контексте сказано: «Увеличение масштаба проектов не имеет никакого значения [в отношении к карьерному росту]»
Не потому что я тут такой умный разумный. Не умнее вас, наверное. А потому что смотрю на все со стороны. И имею собственный программерский опыт, в том числе и управленческий, чтобы делать какие-то подобные умозаключения.
И я не говорю, что вам надо меняться. Если вообще говорить о советах, то выше есть много классных комментов — именно советов. Обоснованных. И проплюсованных. А я от советов воздержусь, в том числе и по причине разницы в возрасте и опыте. Но чего мне действительно хотелось бы, так это постараться донести понимание ситуации до вас. Хотя бы просто взгляд с другой стороны. Вы упорно смотрите с одного угла и не желаете понять тех, кто смотрит по-другому. Вы пытаете объяснить коллегам, что эти работодатели какие-то странные, ничего не понимают. И, как известно, когда все вокруг странные, то обычно проблема не во всех.
Подчеркиваю — это мои личные наблюдения и личное мнение. Отвечаю: скорее всего да. Наверное есть исключения. И очень важное замечание: руководить — не значит перестать писать код. Обычно как раз наоборот — хороший программист-руководитель продолжает писать код, но это уже код более высокого уровня (например, библиотеки, или опенсорс для души). Очень хочу, чтобы меня правильно поняли. Постарайтесь, пожалуйста: хороший программист естественным образом растет не столько вширь, сколько ввысь. С ростом опыта и знаний он начинает шефствовать над другими, более молодыми программистами. Он использует свой опыт эффективно — на всю команду, а не на себя лично. Т.е. он растет по карьерной лестнице. Либо как вариант, начинает преподавать.
И еще раз: да, исключения, есть. И в большинстве случаев это либо гении, либо что-то близкое к гению.
P.S. Хоть я и использую глупое относительное понятие «хороший программист», но думаю, что большинство читающих правильно поймут, о чем идет речь.
Увеличение масштаба проектов не имеет никакого значения, если собственная роль в проекте не меняется. Это не имеет отношения к персональному росту. Опыт, рост вширь — да, рост ввысь — нет.
1. Не следует так гордиться своими слабостями. Исходя из того, что «везде» вы получили отказы, можно сделать вывод, что на собеседовании вы общаетесь в той же манере, в какой написана эта статья.
2. Есть две крайности по типам проектов: А) где все строится на элегантности архитектуры, Б) где все строится на усердии и количестве программистов. Разные продукты делаются по-разному, и требования к разработчикам там разные. В крупных интернет-компаниях делают большие продукты, где все держится не на количестве кода, а не его архитектуре. В то же время, например, в банковском секторе даже в самых крупных компаниях все держится на количестве и надежности кода, а не на архитектуре.
Вы думаете, что в состоянии эффективно работать в любой компании (об этом написано в статье). Это глубокое заблежние, и странно, что оно присуще человеку с вашим не только жизненным, но и профессиональныем опытом. Складывается стойкое впечатление, что вы все это время шли вперед и смотрели только под ноги, не оглядываясь ни назад, ни по сторонам. Моя мысль в том, что ваш опыт пригодится для решения лишьт части задач, которые попадают под пункт Б. А в мейнстриме в интернет-компаниях (мы же про python тут говорим, а не про c++ на сколько я понял) как раз сейчас популярен и нужен программист-А (Б и так хватает). И программистов, так же как и инструменты, зачастую выбирают под задачи.
3. Ваш начальный опыт вообще имеет малое значение для работодателя. Все, что было более 15 лет назад, уже не актуально. Это даже про C++ можно сказать, а про Python я вообще молчу. Так что козырять этим багажом особого смысла нет. Важно, на сколько вы умеете работать в современных условиях, а не сколько кода написали ранее.
4. Ну и важный момент про работу в команде. Вы — индивидуалист. Вы готовы все делать своими руками (из-за этого и не стали до сих пор руководителем). При работе в команде нужно попадать под шаблон команды. Нужно уметь излагаит и понимать других. Это очень хорошо проверячется на собеседовании. Исходя из отказов, опять же предположу, что ваше мышление и общение не стыкуется со стандартными шаблонами. А в больших компаниях большие команды, там нужны люди-компоненты, а не индивидуалисты. Зато там, где нужны именно индивидуалисты, вас брали сразу, видя готовность решать любые задачи (именно решать, при этом не важно как).
5. После 40 лет на мой взгляд хороший программист — это тот, кто руководит. Как то вырисовывается такая картина из жизненного опыта. Если взялись ранно (как вы), то к такому возрасту можно уже высоко вырасти. Если взялись поздно (это не про вас, но мне такие попадались), то извините, но хорошим программистом вам уже не стать.
И ценность руководства не в том, чтобы много денег платили, или в хваставстве, или в ничего неделании. Ценность в масштабе. Карьерный рост — это увеличение масштаба воздействия своей работой. Вы как на вертолете должны взлетать все выше и охватывать все больше, при этом с меньшей детализацией. Это рост. А изучение новых инструментов — это не рост. Это просто опыт, который рано или поздно обесценится в такой динамичной отрасли.
Самая острая для меня — это рассылки. Причем не массовые, которые прочно ассоциируются со спамом, а рассылки-уведомления для сотрудников компании (от которых сотрудники по понятным причинам не могут отписываться, ну и подписываться), чьи адреса находятся на разных доменах в одном аккаунте ПДД.
А. Отсутствие слать почту на разные домены с одного. Ну это реально проблема. Про это уже писали, думаю дополнительные комментарии излишни — все и так понятно: это реально важно и нужно. Т.е. хотя бы включать в рассылки пользователей всех доменов аккаунта, хотя лучше, конечно произвольные адреса.
Б. Отказ в приеме почты из-за подозрений на спам. Часто сталкиваемся с такой проблемой. Подчеркиваю, что шлются письма только на «своих». Некоторые типы писем (где меньше текста и больше цифр) проходят нормально, а некоторые сразу выбивают по всем аккаунтам-получателям SMTP-ошибку типа «try again later». Later, естественно, ничего не меняется. Пробовал решить проблему через саппорт, но получил стандартную отписку про спам. И как бы все — делай что хочешь… С одной стороны понимаю ваши проблемы в этом аспекте, с другой — не понимаю, как проблему решать самому. С gmail таких проблем не было. Да, письма могли попадать в спам, но сервер никогда не отказывался их принимать.
Кстати, речь про именно получение писем на ящики в ПДД, потому что для их отправки мы используем собственные серверы, которые «настроены» в SPF.
Кроме этого, нужно отметить, что регулярно что-то сбоит. Ну об этом вы сами отвечали выше, что, да — бывает. С этим, кстати, действительно можно жить. На гугле тоже сбои бывают, вот один был на той неделе (у нас несколько доменов пока остались гугле).
Дальше замечание про панель управления DNS. У меня один из доменов делегирован к вам. Панель управления ДНС ужасна. Сложно сказать, что в ней неудобно, потому что неудобно все. Когда там порядка 50 записей, включая DKIM и SPF (большие блоки), пользоваться таблицей очень тяжело. Отсутствие банальных сортировок и фильтраций осложняет работу. Очень жду улучшения юзабилити панели.
Первой она быть не обязана. Во-всяком случае, файл, в котором она не первая, прекрасно проходит проверку. Однако, все значения, указанные в SOA-записи, применяются только к тем записям, что следуют ниже нее. Т.е. практического смысла делать ее не первой нет. Тоже самое касается и директивы $TTL (полагаю, что и $ORIGIN, хотя и не проверял).
2. А где в мануале рассказывается про экранирование спецсинтаксиса в расширенном режиме запроса? Очевидно, что при вставке в запрос строк от пользователя, необходимо обеспечить некий уровень экранирования (в самом жестком режиме запретить все).
3. Какой клиент лучше всего использовать для работы со SphinxQL из PHP? mysqli?