IBM под названием PL/I. Это была более современная версия Кобола,
PL/I ну ни разу не "версия Кобола", это совсем другой язык. Я понимаю, что это так в оригинале, но лично у меня такие фразы вызывают подозрение, а знает ли автор реально то, о чем пишет?
Если что, я знаю оба языка, хотя на коболе программировал всего ничего.
Ну я регулярно вижу в том числе на Хабре предложения составить стандарт на то, что должен знать и уметь программист. Вариант того же самого - матрица компетенций.
В тоже время довольно очевидно, что между веб программистом и разработчиком чего-то embedded почти нет пересечений по инструментарию и навыкам. И набор навыков разработчика с 10 годами опыта отличается в разы от того же набора начинающего. И эти матрицы или стандарты, как их ни назови, будут устаревать скажем раз в пять лет наверняка.
Довольно очевидно, что ВУЗы и курсы зарабатывают деньги не на трудоустройстве выпускников в компании - иначе мнение компаний интересовало бы их гораздо больше.
Я вам больше скажу - у нас есть курсы внутри компании. Я им говорю - ребятушки, вот у вас есть учебный курс "Apache Spark для непонятно кого", там вы рассказываете, как программировать на Scala, Java и Python. Выбросьте Python, оставьте первые два - нам так будет лучше. И я знаю коллег, которым надо наоборот - оставить только Python.
То есть, мы просим имеющийся курс сократить. И что вы думаете они мне ответили? "Приведи человек 60 слушателей, мы для вас сделаем курс под заказ". И это я внутренний потребитель их результатов работы.
Ну, строго говоря, откуда мы знаем, что им трудно, а что нет? Я не могу исключить, что собака чувствует много запахов одновременно и может их ассоциировать с продуктами. Может и не всеми сразу, но теми что ей интересны. Ну а что-то и помнит разумеется.
Ну вот я и говорю, у меня полное впечатление, что эту фигню я уже читал. Т.е. это не первый перевод или пересказ из какого-то одного источника, который сам с историей не знаком, переводчиком, который не знаком тоже.
Ну я нашел некую структуру в терминах C. Но к ней не было никаких слов пояснения.
То есть ищется запись типа SRV со стандартным префиксом и суффиксом в виде имени домена.
Я поясню, в чем у меня проблема. У меня DNS георезервированный. Т.е. если я в одном ЦОД, он мне вернет один список KDC, если в другом - другой. И этих KDC там будет штук 30-40, причем с разными весами и приоритетами. Вот этот самый множественный выбор все и осложняет. А некоторые KDC при этом точно брать нельзя, потому что они TGT не выдают (я это априори знаю). А так-то сам список я знаю как достать, это давно реализовано.
Поверьте, это вообще мало кто знает. Меня недавно наши безопасники спрашивали - а как вы аутентифицируете сервер (KDC) при запросе TGT или TGS. Я им навскидку отвечаю - а никак. Мы ему просто доверяем. А вот попробуйте доказать с документами, что это именно так, а не иначе.
Погодите, а каким боком тут размеры? Во-первых, я как раз да, не обнюхиваю, а собака при открытой двери (а может и при закрытой) вполне может унюхать, что там лежит. Не исключаю даже. что все продукты сразу (ну, все какие можно опознать по запаху). То есть, в каком-то смысле они не помнят, что лежит, а просто сразу опознают все запахи, не заглядывая на полки?
Уж поверьте, я гуглил много раз - количество информации по этой теме довольно скудное.
Я без претензий, вы могли на чей-то код опираться, но вы вот вроде утверждаете, что реализовали что-то типа kinit. А как же вы его реализовали, если не знаете, какой формат у keytab? Где-то же вы информацию брали?
Хотела начать текст с шутки про то, что раз инструкции никто не читает, то и писать их не обязательно.
Пардон, но какая же это шутка? Это чистая правда. Никто не читает. Но наличие инструкции, особенно актуальной, позволяет пользователя послать ее читать, пока ты занимаешься другими более срочными делами, чем техподдержка этих тех, кто не читает...
Да у меня такое впечатление, что этот текст я уже видел, потому что помню эту чепуху. Ну посудите сами:
Одной из первых реляционных СУБД была dBase-II от компании Ashton-Tate. Она была выпущена в 1979 году
Называть одной из первых реляционных СУБД dBase, и при этом игнорировать тот факт, что до этого у IBM была System R, которая эксплуатировалась - еще в 1977... а еще была QBE, а в начале 80-х уже были и SQL/DS, и оракл...
Согласен. И дело даже не только в том, что "зачем нужна вся эта толпа в современной разработке". Дело в том, что например, ответ на вопрос, реализуемо ли требование, может выясниться именно в процессе разработки. И никак не раньше. И в моей практике достаточно типичным результатом разработки является скажем такой: "Мы это сделаем, вам это будет стоить столько-то, заказывайте сервера, столько-то штук, такой-то конфигурации. После чего заказчик отвечает: "Ну ок, я подумаю" - и как правило не возвращается. Или возвращается с еще одним потребителем той же фичи и двумя чемоданами денег.
Ну т.е. не только он не знает, можем ли мы создать - мы точно так же не знаем ответа на такой вопрос.
В итоге, SMART применительно к требованиям я бы назвал желательным свойством. Если они не такие, с ними зачастую тоже можно работать, и часть заказчиков готова оплачивать доработку требований до такого состояния.
А, ну да, логично. Это же не мама писала, а ребенок записывал, а ребенок возможно и не знает ни кобола, ни PL/1.
Причем если посмотреть на годы появления, то Кобол это 1959, а PL/1 это 1964. Т.е. это языки примерно одного поколения.
Я посмотрел. В оригинале именно так. Ну т.е. может быть неаккуратно написали конечно.
PL/I ну ни разу не "версия Кобола", это совсем другой язык. Я понимаю, что это так в оригинале, но лично у меня такие фразы вызывают подозрение, а знает ли автор реально то, о чем пишет?
Если что, я знаю оба языка, хотя на коболе программировал всего ничего.
Ну я регулярно вижу в том числе на Хабре предложения составить стандарт на то, что должен знать и уметь программист. Вариант того же самого - матрица компетенций.
В тоже время довольно очевидно, что между веб программистом и разработчиком чего-то embedded почти нет пересечений по инструментарию и навыкам. И набор навыков разработчика с 10 годами опыта отличается в разы от того же набора начинающего. И эти матрицы или стандарты, как их ни назови, будут устаревать скажем раз в пять лет наверняка.
Довольно очевидно, что ВУЗы и курсы зарабатывают деньги не на трудоустройстве выпускников в компании - иначе мнение компаний интересовало бы их гораздо больше.
Я вам больше скажу - у нас есть курсы внутри компании. Я им говорю - ребятушки, вот у вас есть учебный курс "Apache Spark для непонятно кого", там вы рассказываете, как программировать на Scala, Java и Python. Выбросьте Python, оставьте первые два - нам так будет лучше. И я знаю коллег, которым надо наоборот - оставить только Python.
То есть, мы просим имеющийся курс сократить. И что вы думаете они мне ответили? "Приведи человек 60 слушателей, мы для вас сделаем курс под заказ". И это я внутренний потребитель их результатов работы.
Ну, строго говоря, откуда мы знаем, что им трудно, а что нет? Я не могу исключить, что собака чувствует много запахов одновременно и может их ассоциировать с продуктами. Может и не всеми сразу, но теми что ей интересны. Ну а что-то и помнит разумеется.
Ну вот я и говорю, у меня полное впечатление, что эту фигню я уже читал. Т.е. это не первый перевод или пересказ из какого-то одного источника, который сам с историей не знаком, переводчиком, который не знаком тоже.
Да, спасибо, именно эту и нашел.
Ну я нашел некую структуру в терминах C. Но к ней не было никаких слов пояснения.
Я поясню, в чем у меня проблема. У меня DNS георезервированный. Т.е. если я в одном ЦОД, он мне вернет один список KDC, если в другом - другой. И этих KDC там будет штук 30-40, причем с разными весами и приоритетами. Вот этот самый множественный выбор все и осложняет. А некоторые KDC при этом точно брать нельзя, потому что они TGT не выдают (я это априори знаю). А так-то сам список я знаю как достать, это давно реализовано.
Поверьте, это вообще мало кто знает. Меня недавно наши безопасники спрашивали - а как вы аутентифицируете сервер (KDC) при запросе TGT или TGS. Я им навскидку отвечаю - а никак. Мы ему просто доверяем. А вот попробуйте доказать с документами, что это именно так, а не иначе.
Ну я решил для начала спросить. Искать в коде то, чего там нет, может быть проблематично.
В принципе, мне тоже нужна ограниченная функциональность, но немного пошире.
Понятно.
Погодите, а каким боком тут размеры? Во-первых, я как раз да, не обнюхиваю, а собака при открытой двери (а может и при закрытой) вполне может унюхать, что там лежит. Не исключаю даже. что все продукты сразу (ну, все какие можно опознать по запаху). То есть, в каком-то смысле они не помнят, что лежит, а просто сразу опознают все запахи, не заглядывая на полки?
Уж поверьте, я гуглил много раз - количество информации по этой теме довольно скудное.
Я без претензий, вы могли на чей-то код опираться, но вы вот вроде утверждаете, что реализовали что-то типа kinit. А как же вы его реализовали, если не знаете, какой формат у keytab? Где-то же вы информацию брали?
А, кажется я понял. PKINIT, да...
Пардон, но какая же это шутка? Это чистая правда. Никто не читает. Но наличие инструкции, особенно актуальной, позволяет пользователя послать ее читать, пока ты занимаешься другими более срочными делами, чем техподдержка этих тех, кто не читает...
Да у меня такое впечатление, что этот текст я уже видел, потому что помню эту чепуху. Ну посудите сами:
Называть одной из первых реляционных СУБД dBase, и при этом игнорировать тот факт, что до этого у IBM была System R, которая эксплуатировалась - еще в 1977... а еще была QBE, а в начале 80-х уже были и SQL/DS, и оракл...
Два простых вопроса:
у вас есть строгое описание формата keytab?
знаете ли вы алгоритм выбора KDC, если в krb5.conf написано dns_lookup_kdc?
А что тут такого? Я тоже помню что у меня есть в холодильнике :) Вот на какой оно полке - это другое, тут я могу запутаться...
Согласен. И дело даже не только в том, что "зачем нужна вся эта толпа в современной разработке". Дело в том, что например, ответ на вопрос, реализуемо ли требование, может выясниться именно в процессе разработки. И никак не раньше. И в моей практике достаточно типичным результатом разработки является скажем такой: "Мы это сделаем, вам это будет стоить столько-то, заказывайте сервера, столько-то штук, такой-то конфигурации. После чего заказчик отвечает: "Ну ок, я подумаю" - и как правило не возвращается. Или возвращается с еще одним потребителем той же фичи и двумя чемоданами денег.
Ну т.е. не только он не знает, можем ли мы создать - мы точно так же не знаем ответа на такой вопрос.
В итоге, SMART применительно к требованиям я бы назвал желательным свойством. Если они не такие, с ними зачастую тоже можно работать, и часть заказчиков готова оплачивать доработку требований до такого состояния.