Как стать автором
Обновить
84
0.9

Пользователь

Отправить сообщение

Ну, строго говоря, откуда мы знаем, что им трудно, а что нет? Я не могу исключить, что собака чувствует много запахов одновременно и может их ассоциировать с продуктами. Может и не всеми сразу, но теми что ей интересны. Ну а что-то и помнит разумеется.

Ну вот я и говорю, у меня полное впечатление, что эту фигню я уже читал. Т.е. это не первый перевод или пересказ из какого-то одного источника, который сам с историей не знаком, переводчиком, который не знаком тоже.

Да, спасибо, именно эту и нашел.

Ну я нашел некую структуру в терминах C. Но к ней не было никаких слов пояснения.

 То есть ищется запись типа SRV со стандартным префиксом и суффиксом в виде имени домена.

Я поясню, в чем у меня проблема. У меня DNS георезервированный. Т.е. если я в одном ЦОД, он мне вернет один список KDC, если в другом - другой. И этих KDC там будет штук 30-40, причем с разными весами и приоритетами. Вот этот самый множественный выбор все и осложняет. А некоторые KDC при этом точно брать нельзя, потому что они TGT не выдают (я это априори знаю). А так-то сам список я знаю как достать, это давно реализовано.

Поверьте, это вообще мало кто знает. Меня недавно наши безопасники спрашивали - а как вы аутентифицируете сервер (KDC) при запросе TGT или TGS. Я им навскидку отвечаю - а никак. Мы ему просто доверяем. А вот попробуйте доказать с документами, что это именно так, а не иначе.

Ну я решил для начала спросить. Искать в коде то, чего там нет, может быть проблематично.

В принципе, мне тоже нужна ограниченная функциональность, но немного пошире.

Погодите, а каким боком тут размеры? Во-первых, я как раз да, не обнюхиваю, а собака при открытой двери (а может и при закрытой) вполне может унюхать, что там лежит. Не исключаю даже. что все продукты сразу (ну, все какие можно опознать по запаху). То есть, в каком-то смысле они не помнят, что лежит, а просто сразу опознают все запахи, не заглядывая на полки?

Уж поверьте, я гуглил много раз - количество информации по этой теме довольно скудное.

Я без претензий, вы могли на чей-то код опираться, но вы вот вроде утверждаете, что реализовали что-то типа kinit. А как же вы его реализовали, если не знаете, какой формат у keytab? Где-то же вы информацию брали?

А, кажется я понял. PKINIT, да...

Хотела начать текст с шутки про то, что раз инструкции никто не читает, то и писать их не обязательно.

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

Да у меня такое впечатление, что этот текст я уже видел, потому что помню эту чепуху. Ну посудите сами:

Одной из первых реляционных СУБД была dBase-II от компании Ashton-Tate. Она была выпущена в 1979 году

Называть одной из первых реляционных СУБД dBase, и при этом игнорировать тот факт, что до этого у IBM была System R, которая эксплуатировалась - еще в 1977... а еще была QBE, а в начале 80-х уже были и SQL/DS, и оракл...

Два простых вопроса:

  • у вас есть строгое описание формата keytab?

  • знаете ли вы алгоритм выбора KDC, если в krb5.conf написано dns_lookup_kdc?

А что тут такого? Я тоже помню что у меня есть в холодильнике :) Вот на какой оно полке - это другое, тут я могу запутаться...

Согласен. И дело даже не только в том, что "зачем нужна вся эта толпа в современной разработке". Дело в том, что например, ответ на вопрос, реализуемо ли требование, может выясниться именно в процессе разработки. И никак не раньше. И в моей практике достаточно типичным результатом разработки является скажем такой: "Мы это сделаем, вам это будет стоить столько-то, заказывайте сервера, столько-то штук, такой-то конфигурации. После чего заказчик отвечает: "Ну ок, я подумаю" - и как правило не возвращается. Или возвращается с еще одним потребителем той же фичи и двумя чемоданами денег.

Ну т.е. не только он не знает, можем ли мы создать - мы точно так же не знаем ответа на такой вопрос.

В итоге, SMART применительно к требованиям я бы назвал желательным свойством. Если они не такие, с ними зачастую тоже можно работать, и часть заказчиков готова оплачивать доработку требований до такого состояния.

Ну, есть такая штука, как Apache POI, это один из самых старых, и самых продвинутых пакетов поддержки форматов Офиса, помимо собственно COM. Так что выбор (одного из) языков для JVM - он в принципе-то вполне логичный.

А так да, я бы тоже начал писать на груви, а не на Java :) Ну или на скале. Не то чтобы на скриптовом языке в полном смысле этого слова, но на чуть более гибком, чем Java.

Простой парсер excel на java - это где-то 10 строк. Три вложенных цикла - по страницам .xls файла, строкам, колонкам. Плюс еще 10 строк - преобразование типов данных, кои бывают разные, в разные же типы базы. Плюс еще строк 10 - само сохранение.

Даже если я ошибаюсь в два раза - это не существенно, я такое реально делал раз десять за свою практику. Реально можно написать за час, не сильно напрягаясь. За день - если вы никогда этого не делали, тоже норм. И если вы на windows, и у вас есть доступ к COM объекту Excel, то на любом из языков с поддержкой COM, то еще чуть проще.

А вот если вы ко мне придете и попросите чтобы моя команда это написала (причем переносимое на линукс) - я тоже попрошу неделю срока. Потому что не знаю, кто именно будет писать, и как глубоко придется объяснить человеку суть дела, сколько времени уйдет на тестирование, и т.п. Иными словами - оценку вам выкатили совершенно адекватную. При мне начинающий java-программист писал такое месяц, и при этом все еще не закончил.

А за сэкономленное время других людей - грейд не дают, как и прибавку к зп.

Это смотря где. Хотя вы правы - понимание того, сколько стоит такая активность есть далеко не всегда. И не у всех. Но встречается.

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

Ну то есть, меня лично допустим смущает отказ от очередей - потому что у меня был опыт развертывания ActiveMQ за один день, и использования в проекте. Т.е. за день - все вместе, и оно уже заработало, вместе с кодом. Но не имея такого же опыта вы вполне можете принять и другое решение, просто потому, что не можете оценить сроки внедрения.

Опять же - у нас в большой компании можно просто зайти на портал заказа железок, и выбрать там из меню кафку, задать конфигурацию (использовав готовый калькулятор) - и завтра она уже работает. А в маленькой команде сначала еще и настроить придется.

Ну как-бы все имеет свою цену. Вы не использовали кафку или какое-то решение с очередями, назовем его условно MQ. Вместо этого вы сделали свой велосипед для асинхронного выполнения длительных задач. Никуда же не деться - длительные задачи нужно развязать от обработки коротких запросов. Ваш алгоритм вам тоже будет стоить денег - на сопровождение. Это не значит что условная кафка не стоила бы - это уже надо сравнивать.

Если у вас не было опыта с такими решениями - ну это тоже решение, работать с тем что умеешь. Особенно в маленькой команде. И у него свои недостатки и ограничения.

Выражаясь языком экономики, стоимость ритуалов SCRUM составляет 15% от стоимости команды. Эти средства уходят не на разработку, а на разговоры о том, кто что сегодня сделает, жалобы на процессы, игру в карты, показ сделанной работы руководству собственной фирмы и показ того же самого представителям заказчика.

В том-то и дело. Вы не можете выкинуть планирование (спринта, или любого другого периода). Планирование все равно будет - другое дело, что оно будет например происходить в другое время и в другом месте. Например, в голове или на бумажке у тимлида. Но само по себе оно никуда не денется, или у вас будет бардак почище эджайла.

Тоже самое - демо. Вы конечно можете никому не показывать результаты своего релиза - но это в конечном счете отольется вам же лишней работой по сопровождению. Ваш заказчик должен видеть, что вы сделали. Это даже не столько реклама себя, любимого, сколько обучение потребителя, чтобы он понимал, какие новые фишки появились, какие проблемы решены.

Информация

В рейтинге
1 361-й
Зарегистрирован
Активность