А Вы не скромничайте и попробуйте сами. Это не так сложно, как кажется. Самое сложное, что там есть — это не совсем традиционное использование рекурсии. И уж точно тут нет никакой олимпиадной специфики. Подобные задачки время от времени рассматривают на sql.ru, посмотрите там на примеры разбора.
За конструктивный подход спасибо, так можно и подискутировать. Хотя я несколько опасаюсь Вашего «категорического несогласия» (цитата). Зачем же категорично так?
Английская Википедия тоже называет SQL специализированным языком
(DSL), используемым в программировании. По английски просто писать, что query language является ещё каким-то language — это толочь воду в ступе, название самоопредеяющее.
На самом деле порывшись в Википедии я так понимаю, что Вы различаете компьютерные языки и в них подкласс языков программирования, а я все компьютерные языки называю ЯП. Если честно, не знаю насколько это сложившаяся терминология, даже несморя на профильное образование и десятилетия работы в области ИТ.
В моём представлении компьютерным языком можно назвать вообще что угодно, связанное с языком и компьютером. Например то, что мне какая-то работающая на компьютере программа покажет на экране. Текстовый вывод любой программы, особенно если он человеко-подобный (типа введите число) можно назвать компьютерным языком. Или все эти текстовые протоколы, на которых общаются сами программы (http, smtp и прочее). Сюда же, кстати, SQL вписывается. Короче слишком общо, мне не нравится. Хотя да, языки разметки в ЯП записывать тоже не совсем корректно. С третьей стороны на том же XML есть XSLT и это уже ЯП в самом что ни на есть программистском понимании. Да и на CSS порой такой интерактив делают, что ой. Так что по крайней мере не всё так однозначно.
И ещё хочу пару слов в защиту Википедии сказать. Почему-то её принято походу пинать, что она не является авторитетом. Почему ж не является? Ещё как является. Истиной в последней инстанции не является, а энциклопедическим изданием является и весьма неплохим. В Hitchhikers Guide to the Galaxy ляпов куда как больше.
А надо? Если делать разбор задачи, то нужно по статье на каждую. Просто опубликовать ответы, на мой вкус, неинтересно, их никто тогда не будет и пробовать решать. Ну и я не вижу никакой запредельной сложности в этих задачах.
Если честно, то для меня язык программирования (ЯП) — это всё, на чём человек может объяснить компьютеру, что тот должен делать. Так что, IMNSHO, SQL — это несомненно язык программирования. Специализированный. И Википедия тоже со мной согласна. Да, если бы язык имел устоявшееся название СЯЗ (Структурированный язык запросов), то с точки зрения русского языка его бы чаще называли языком запросов, как это и происходит в английском. А так, все формальные языки, придуманные для программирования ЭВМ, вполне корректно называть ЯП.
PL/SQL это как бы не SQL с дополнениями ЯП, а совершенно самостоятельный язык программирования с встроенной возможностью использовать в нём SQL. Тоже, кстати, довольно специализированный. Возможно, название было взято по аналогии с PL/I, который был популярен во время появления на рынке PL/SQL, хотя корнями PL/SQL ближе к ADA.
У меня просьба к коментаторам: если Вам кажется, что в тексте ошибка, то лучше в личные сообщения.
Дело не в любви к теории заговоров, а в чрезмерной агрессивности яндексных сервисов в сочетании с известными фактами о невидимом стуке. Я вот тоже регулярно смотрю на что-то яндексное из приложений и так же регулярно сношу, так как лезет яндекс в мою личную жизнь через мобильные приложения куда как наглее, чем я готов стерпеть. Nothing personal, как говорится.
Ничего, Воронеж справится. Вот Вам хорошо. Хозяев Алиса слушает внимательно, а у меня забывает всё напрочь. Реакция на предыдущую фразу у меня бывает только если повторяю Ваши примеры. А у меня только так:
И ещё странно, что Алиса всё норовит в поиск послать. Пусть бы сама искала и озвучивала. Если не может от своего имени, то пусть отвечает типа «В этих ваших интернетах говорят ...»
Когда Алиса появилась впервые, её зачем-то назвали ИИ. Было конечно интересно. Первое, что я сделал — проверил её на интеллект нехитрым тестом:
Я: Дважды два.
А: Четыре.
Я: Прибавь два.
А несёт какой-то бред.
Суть теста такая, что любая интеллектуальная деятельность должна иметь контекст и память того, что было только что. У Алисы этого нет. В этой статье с интересом увидел, что оказывается есть, причём, если верить статье, используется повсеместно, вроде как любое произнесённое заполняет информацию в некоторой виртуальной «форме». И ещё эта, как её, анафора. Со второй попытки я сумел повторить пример с Эверестом из статьи, в первый раз моя фраза распозналась не совсем верно, и оно не сработало. Тогда я попробовал вызвать подобное поведение ещё хоть где-то. Не могу. Не выходит:
Я: Погода на завтра.
А: Завтра в Москве…
Я: А в Воронеже?
А: А ты где живёшь?
Короче, пока Алиса постоянно забывает нить разговора и не помнит даже предыдущей моей фразы, она в лучшем случае похожа на дауна. Человек, который не помнит предыдущей фразы ни своей, ни собеседника в реальной жизни производит пугающее впечатление.
Я думаю, что нужно сделать так, чтобы Алиса как раз всё-всё помнила и отвечала на вопросы только в контектсе предыдущих реплик. Пусть они забываются со временем (через несколько часов), пусть сбрасываются на специальные фразы типа «Так, давай всё с начала», но контекст забывать нельзя.
По моему личному мнению в любой вводной статье по ITSM или ITIL просто необходимо разъяснить чем связаны и чем отилчаются эти два невнятных набора букв.
Бэклог — это грубо говоря то, что ещё осталось сделать. И относиться может как к поддержке, так и к развитию. Я вот сегодня три запроса закрыл, ещё пять осталось. Вот пять запросов — это мой бэклог и есть.
С самым главным понятно. Требуется добавить ещё кое-что для большей скукиэффективности. А именно планирование расходов (в виде бюджетирования) и контроль исполнения бюджета.
Приведённая в статье схема хорошо работает, если мы тратим все доходы в ноль, пусть даже откладывая что-то в резерв. Если же сделать бюджет и организовать контроль его соблюдения, то можно быть значительно гибче, устанавливая планку расходов на любой желаемый уровень. Это может быть полезно в разных случаях: для максимально быстрого накопления денег, на периоды, когда расходы превышают доходы (например, делаем капремонт) или при нерегулярных доходах и т.п…
Да, согласен, смайликов не поставил. Про проще-сложнее — это же просто эпический маразм какой-то. Конечно у каждого уровня поддержки есть свои функции и свои обязанности. Какие именно — зависит от специфики работ. Вы вот явно пишете про работу с внешними клиентами, я чаще имею дело с внутренними IT-системами, но в каждом случае работа уровней поддержки должна быть чётко очерчена.
В типичном моём случае продвижение от 1‑го до 3‑го уровней поддержки выглядит так.
1‑й уровень, он же HelpDesk, принимает обращения всех пользователей, заводит инциденты. Стандартные инциденты, на которые есть опросные карты (что спросить и что сделать при заданных ответах; например, сброс паролей), решаются. По всем остальным делается диспетчеризация на основе тех же опросных карт, и инцидент назначается на 2‑й уровень поддержки. Если пользователи сами заводят инциденты через веб-интерфейс, то инцидент сразу идёт в соответствующую группу, чаще сразу на 2‑й уровень. HelpDesk должен работать быстро, любое отклонение от стандартной ситуации — это перевод инцидента на 2-й уровень. Но HelpDesk должен или установить группу поддержки 2го уровня, или выслать сервиного инженера, чтобы тот разобрался на месте.
2‑й уровень — функциональный. Здесь аналитики, хорошо знакомые с конкретной системой, исследуют действительно ли инцидент имеет место быть и решат его, если для этого достаточно имеющегося в системе функционала. Если выявлены ошибки в коде или повреждены данные, то 2‑й уровень заводит запрос (дефект) к 3‑му ровню поддержки.
3‑й уровень поддержки — разработчики. Решают дефекты, они же баги в системе.
Если выясняется, что баг относится к коробочной версии продукта, на основе которого сделана система, то заводится запрос на поддержку вендору. Это может делать как 2‑й, так и 3‑й уровни поддержки, в зависимости от того, где был выявлен баг — в функционале или в коде. Вендора при этом можно рассматривать как 4‑й уровень поддержки.
И надо правильно расставлять акценты. Не «мы тут не разобрались», а наоборот, «мы тут разобрались основательно и нашли, что проблема куда глубже, чем казалась на первый взгляд. Для её решения привлечён такой-то отдел, который должен выполнить вот это за такое-то время.» Мой опыт показывает, что если поддержка честно пашет, то бизнес готов такое понимать.
А у Вас что происходит, если прилетает инцидент, который сразу видно, что невозможно решить за отведённое в SLA время?
Как правило эскалация бывает обусловлена недостаточной квалификацией для самостоятельного решения задачи.
В моём понимании это не эскалация. Это маршрутизация. Если не по адресу прилетело, то запрос надо переназначить. Если пришло по адресу, а не хватает знаний, то привлекать внутреннюю экспертизу в помощь. Если внутри группы есть специализация, то должен быть и внутренний механизм, как задачи распределяются к подходящему исполнителю.
сбой не там где изначально предполагали, нужно привлечение специалистов другого отдела. Можно заводить дочерний запрос — но по основному инциденту уже идёт время решения по его sla + sla на дочерний инцидент, это 100% превышение по времени
Я предлагаю ставить инцидент на паузу, пока выполняется дочерний запрос. Потому что в текущей ситуации у Вас получается, что инцидент уже почти просрочен, а его надо решать по сути заново, и в таком виде инцидент улетает кому-то в другой отдел. Это подстава в чистом виде. Новый исполнитель будет наказан за не свою плохую работу.
Вообще организацию работ нужно продумывать заранее. Как предполагается поступать грамотно в этой ситуации в соответствии с действующими регламентами? Это типовая ситуация. Я подозреваю, что процедуры работы не очень хорошо продуманы, их надо оптимизировать.
На мой взгляд это сильно зависит от характера работ. Время решения конечно можно гарантировать, но если найдутся проблемы, которые не могут быть решены за ограниченное время, то надо смириться с тем, что иногда гарантия будет нарушаться. Или не завязываться на это в SLA.
Какая стратегия лучше — зависит от характера работ и маркетинговых соображений. Вполне органично может смотреться что-то типа «мы или успеваем за сутки, или клиент пользуется услугой бесплатно весь следующий месяц». А вот «мы решим любую проблему в вашей ERP-системе за сутки» — это явное враньё, никто не поверит.
Английская Википедия тоже называет SQL специализированным языком
(DSL), используемым в программировании. По английски просто писать, что query language является ещё каким-то language — это толочь воду в ступе, название самоопредеяющее.
На самом деле порывшись в Википедии я так понимаю, что Вы различаете компьютерные языки и в них подкласс языков программирования, а я все компьютерные языки называю ЯП. Если честно, не знаю насколько это сложившаяся терминология, даже несморя на профильное образование и десятилетия работы в области ИТ.
В моём представлении компьютерным языком можно назвать вообще что угодно, связанное с языком и компьютером. Например то, что мне какая-то работающая на компьютере программа покажет на экране. Текстовый вывод любой программы, особенно если он человеко-подобный (типа введите число) можно назвать компьютерным языком. Или все эти текстовые протоколы, на которых общаются сами программы (http, smtp и прочее). Сюда же, кстати, SQL вписывается. Короче слишком общо, мне не нравится. Хотя да, языки разметки в ЯП записывать тоже не совсем корректно. С третьей стороны на том же XML есть XSLT и это уже ЯП в самом что ни на есть программистском понимании. Да и на CSS порой такой интерактив делают, что ой. Так что по крайней мере не всё так однозначно.
И ещё хочу пару слов в защиту Википедии сказать. Почему-то её принято походу пинать, что она не является авторитетом. Почему ж не является? Ещё как является. Истиной в последней инстанции не является, а энциклопедическим изданием является и весьма неплохим. В Hitchhikers Guide to the Galaxy ляпов куда как больше.
Если честно, то для меня язык программирования (ЯП) — это всё, на чём человек может объяснить компьютеру, что тот должен делать. Так что, IMNSHO, SQL — это несомненно язык программирования. Специализированный. И Википедия тоже со мной согласна. Да, если бы язык имел устоявшееся название СЯЗ (Структурированный язык запросов), то с точки зрения русского языка его бы чаще называли языком запросов, как это и происходит в английском. А так, все формальные языки, придуманные для программирования ЭВМ, вполне корректно называть ЯП.
PL/SQL это как бы не SQL с дополнениями ЯП, а совершенно самостоятельный язык программирования с встроенной возможностью использовать в нём SQL. Тоже, кстати, довольно специализированный. Возможно, название было взято по аналогии с PL/I, который был популярен во время появления на рынке PL/SQL, хотя корнями PL/SQL ближе к ADA.
У меня просьба к коментаторам: если Вам кажется, что в тексте ошибка, то лучше в личные сообщения.
И ещё странно, что Алиса всё норовит в поиск послать. Пусть бы сама искала и озвучивала. Если не может от своего имени, то пусть отвечает типа «В этих ваших интернетах говорят ...»
Я: Дважды два.
А: Четыре.
Я: Прибавь два.
А несёт какой-то бред.
Суть теста такая, что любая интеллектуальная деятельность должна иметь контекст и память того, что было только что. У Алисы этого нет. В этой статье с интересом увидел, что оказывается есть, причём, если верить статье, используется повсеместно, вроде как любое произнесённое заполняет информацию в некоторой виртуальной «форме». И ещё эта, как её, анафора. Со второй попытки я сумел повторить пример с Эверестом из статьи, в первый раз моя фраза распозналась не совсем верно, и оно не сработало. Тогда я попробовал вызвать подобное поведение ещё хоть где-то. Не могу. Не выходит:
Я: Погода на завтра.
А: Завтра в Москве…
Я: А в Воронеже?
А: А ты где живёшь?
Короче, пока Алиса постоянно забывает нить разговора и не помнит даже предыдущей моей фразы, она в лучшем случае похожа на дауна. Человек, который не помнит предыдущей фразы ни своей, ни собеседника в реальной жизни производит пугающее впечатление.
Я думаю, что нужно сделать так, чтобы Алиса как раз всё-всё помнила и отвечала на вопросы только в контектсе предыдущих реплик. Пусть они забываются со временем (через несколько часов), пусть сбрасываются на специальные фразы типа «Так, давай всё с начала», но контекст забывать нельзя.
А болталка — прикольно, но совершенно бесполезно.
Откидывать нужно то, что никому особо ненужно.
—Но ведь не работает же?
—Ну и пусть не работает, всего в мире не исправить.
А что бэклог? И почечму он опять?
скукиэффективности. А именно планирование расходов (в виде бюджетирования) и контроль исполнения бюджета.Приведённая в статье схема хорошо работает, если мы тратим все доходы в ноль, пусть даже откладывая что-то в резерв. Если же сделать бюджет и организовать контроль его соблюдения, то можно быть значительно гибче, устанавливая планку расходов на любой желаемый уровень. Это может быть полезно в разных случаях: для максимально быстрого накопления денег, на периоды, когда расходы превышают доходы (например, делаем капремонт) или при нерегулярных доходах и т.п…
В типичном моём случае продвижение от 1‑го до 3‑го уровней поддержки выглядит так.
1‑й уровень, он же HelpDesk, принимает обращения всех пользователей, заводит инциденты. Стандартные инциденты, на которые есть опросные карты (что спросить и что сделать при заданных ответах; например, сброс паролей), решаются. По всем остальным делается диспетчеризация на основе тех же опросных карт, и инцидент назначается на 2‑й уровень поддержки. Если пользователи сами заводят инциденты через веб-интерфейс, то инцидент сразу идёт в соответствующую группу, чаще сразу на 2‑й уровень. HelpDesk должен работать быстро, любое отклонение от стандартной ситуации — это перевод инцидента на 2-й уровень. Но HelpDesk должен или установить группу поддержки 2го уровня, или выслать сервиного инженера, чтобы тот разобрался на месте.
2‑й уровень — функциональный. Здесь аналитики, хорошо знакомые с конкретной системой, исследуют действительно ли инцидент имеет место быть и решат его, если для этого достаточно имеющегося в системе функционала. Если выявлены ошибки в коде или повреждены данные, то 2‑й уровень заводит запрос (дефект) к 3‑му ровню поддержки.
3‑й уровень поддержки — разработчики. Решают дефекты, они же баги в системе.
Если выясняется, что баг относится к коробочной версии продукта, на основе которого сделана система, то заводится запрос на поддержку вендору. Это может делать как 2‑й, так и 3‑й уровни поддержки, в зависимости от того, где был выявлен баг — в функционале или в коде. Вендора при этом можно рассматривать как 4‑й уровень поддержки.
Как SLA я в другой статье рассматривал.
И надо правильно расставлять акценты. Не «мы тут не разобрались», а наоборот, «мы тут разобрались основательно и нашли, что проблема куда глубже, чем казалась на первый взгляд. Для её решения привлечён такой-то отдел, который должен выполнить вот это за такое-то время.» Мой опыт показывает, что если поддержка честно пашет, то бизнес готов такое понимать.
А у Вас что происходит, если прилетает инцидент, который сразу видно, что невозможно решить за отведённое в SLA время?
В моём понимании это не эскалация. Это маршрутизация. Если не по адресу прилетело, то запрос надо переназначить. Если пришло по адресу, а не хватает знаний, то привлекать внутреннюю экспертизу в помощь. Если внутри группы есть специализация, то должен быть и внутренний механизм, как задачи распределяются к подходящему исполнителю.
Я предлагаю ставить инцидент на паузу, пока выполняется дочерний запрос. Потому что в текущей ситуации у Вас получается, что инцидент уже почти просрочен, а его надо решать по сути заново, и в таком виде инцидент улетает кому-то в другой отдел. Это подстава в чистом виде. Новый исполнитель будет наказан за не свою плохую работу.
Вообще организацию работ нужно продумывать заранее. Как предполагается поступать грамотно в этой ситуации в соответствии с действующими регламентами? Это типовая ситуация. Я подозреваю, что процедуры работы не очень хорошо продуманы, их надо оптимизировать.
Какая стратегия лучше — зависит от характера работ и маркетинговых соображений. Вполне органично может смотреться что-то типа «мы или успеваем за сутки, или клиент пользуется услугой бесплатно весь следующий месяц». А вот «мы решим любую проблему в вашей ERP-системе за сутки» — это явное враньё, никто не поверит.