Программисты. Программисты, это, конечно, танковые войска. Их отправляют в прорыв – захватывать новые земли (колбасить код), брать ДЗОТы и ДОТы (фичи) и даже укрепрайоны (новые фреймворки). Лучше их – нет, ага. Но – требуют топлива, ремонта, обслуживания (бабло, обучение, инфраструктура соответственно).Продолжение...
Сильны они и в обороне (техподдержка), ибо грамотно зарытый в кирпичи танк выбить практически невозможно… (знание принципа работы, умение разобраться в коде). Обзор маловат, но если разместить в ключевых позициях… Но в обороне их держать дорого, и, обычно, бессмысленно.
пятница, 20 сентября 2013 г.
Как на войне
Вычитал в архивах у Макса Захарова забавное о программистах:
четверг, 19 сентября 2013 г.
Алексей Шамин: О консультантах
Есть такой хороший человек - Алексей Шамин. Леша совсем не светится в "этих ваших интернетах", но у него определенно есть то, чем можно круто посветить.
Например вот Лешин креатив о консультантах (это просто обязано стать достоянием общественности :) ):
Репост Макса Дорофеева
Например вот Лешин креатив о консультантах (это просто обязано стать достоянием общественности :) ):
Когда я стану консультантом,
Смогу я в фирмы приходить,
И там людЯм за их же деньги
"Говно!" - открыто говорить.
Они со мною будут спорить,
Кричать что это все не так:
"Говна у нас на фирме нету
Ты консультант или дурак?
Мы уникальная контора!
У нас особенный процесс!
А кто не понял это сразу,
Пускай идет гуляет в лес.
Совет простой нам не подходит,
Стандартный метод не для нас!
Зачем мы деньги заплатили?
Не консультант ты - пи.арас..."
И я скажу, в глаза им глядя,
В ответе за свои слова:
"Большие видел в жизни жопы
Но больше вашей никогда!"
Репост Макса Дорофеева
пятница, 13 сентября 2013 г.
С праздником, коллеги!
Старая, но самая любимая картинка на тему:
Хорошего всем дня, и хорошего кода.
Хорошего всем дня, и хорошего кода.
пятница, 6 сентября 2013 г.
CSG. Аутсорсят тестирование!
Друзья, недавно мне в скайп постучался один хороший человек. Мы с ним общались года два назад по поводу большого сотрудничества. По независимым от нас причинам поработать тогда вместе не получилось, зато у меня теперь есть в контакт-листе Владимир. Очень толковый специалист.
Сейчас он со своей командой аутсорсит тестирование. Да, вещь нужна далеко не каждому. Но если вы:
1. Руководите отделом разработки в большой компании,
2. Ваши специалисты гуру в разработке вашего внутреннего продукта, каждый из программистов почти бизнес-аналитик, а бизнес-аналитики потихоньку учат программирование
3. И вам нужно качество (то, что QA), а нарушать идиллию и садить опытного разработчика писать тупые тесты не хочется,
4. А при том набирать "студентов" на написание тестов это лишний "геморрой",
то Владимир и его группа CSG сделают вам красиво.
В такой ситуации лучше "отдать деньгами". Отдайте написание тестовых сценариев на аутсорс профессионалам и все решено.
Про метрики и прочее всякое это вы лучше с ним сами пообщайтесь. Скайп вот - vl.snow
Еще есть презентация.
P.S.: Понятно, что это все типа рекламы (да, да, где мои миллионы), но тенденция в отечественном IT радует. Такие штуки, как аутсорс тестирования, нужно развивать. А, может, они и тестовыми инструментами к 1С владеть будут, все-таки 8.3? Кто знает?
Сейчас он со своей командой аутсорсит тестирование. Да, вещь нужна далеко не каждому. Но если вы:
1. Руководите отделом разработки в большой компании,
2. Ваши специалисты гуру в разработке вашего внутреннего продукта, каждый из программистов почти бизнес-аналитик, а бизнес-аналитики потихоньку учат программирование
3. И вам нужно качество (то, что QA), а нарушать идиллию и садить опытного разработчика писать тупые тесты не хочется,
4. А при том набирать "студентов" на написание тестов это лишний "геморрой",
то Владимир и его группа CSG сделают вам красиво.
В такой ситуации лучше "отдать деньгами". Отдайте написание тестовых сценариев на аутсорс профессионалам и все решено.
Про метрики и прочее всякое это вы лучше с ним сами пообщайтесь. Скайп вот - vl.snow
Еще есть презентация.
P.S.: Понятно, что это все типа рекламы (да, да, где мои миллионы), но тенденция в отечественном IT радует. Такие штуки, как аутсорс тестирования, нужно развивать. А, может, они и тестовыми инструментами к 1С владеть будут, все-таки 8.3? Кто знает?
понедельник, 5 августа 2013 г.
Запрос. Выгрузить() vs Выбрать(). Менеджер объекта?
Недавно просматривал статью "Особенности использования динамических выборок (выборки данных с помощью методов Выбрать...)" из методических рекомендаций (или тут).
В частности, там есть такой момент, который меня удивил:
Конечно, какая эта еще вероятность, того что данные изменятся в момент выборки. Но важен сам принцип.
И все-таки я сомневаюсь. С одной стороны логика подсказывает, что если оно сразу не пишется все в память, значит, читается порциями. А так как еще и зависит от скорости выполнения кода 1С, то может быть хорошо растянуто во времени.
Так же на эту рекомендацию авторитетно ссылается Радченко.
С другой стороны, все сообщения датируются 2008-2009 годом, а сама статья на ИТС и того старше, поди. Может быть что-то поменялось, просто я не знаю где почитать более актуальную статью?
Еще один, самый главный момент для сомнения в том, есть ли разница в работе методов Справочники.Номенклатура.Выбрать() и Запрос.Выполнить().Выбрать().
Да, типы возвращаются разные, но сам механизм и запросы, которые отправляются к БД? Возможно ли, что такая выборка порциями относится только к выборке при обращении к менеджеру объекта, или же с выборкой запроса механизм одинаковый?
Складывается ощущение, что я не правильно понял статью и под динамической выборкой подразумевается именно выборка из менеджера объекта, а не из результата запроса. Действительно, как, например, в сложном "навороченном" запросе выбрать строки с 25 по 50?
Коллеги, кто-то еще интересовался этим?
В частности, там есть такой момент, который меня удивил:
Следует учитывать, что если в процессе обхода выборки данные изменяются (в данной сессии, или другими сессиями), то могут возникать такие ситуации, как получение данных удаленного объекта, получение в выборке одного объекта два раза, не попадание некоторых записей в выборку и т.д.Т.е. они хотят сказать, что вы высоконагруженных системах моя любимая выборка будет "глючить" и придется тянуть здоровенные таблицы в память?
Конечно, какая эта еще вероятность, того что данные изменятся в момент выборки. Но важен сам принцип.
И все-таки я сомневаюсь. С одной стороны логика подсказывает, что если оно сразу не пишется все в память, значит, читается порциями. А так как еще и зависит от скорости выполнения кода 1С, то может быть хорошо растянуто во времени.
Так же на эту рекомендацию авторитетно ссылается Радченко.
С другой стороны, все сообщения датируются 2008-2009 годом, а сама статья на ИТС и того старше, поди. Может быть что-то поменялось, просто я не знаю где почитать более актуальную статью?
Еще один, самый главный момент для сомнения в том, есть ли разница в работе методов Справочники.Номенклатура.Выбрать() и Запрос.Выполнить().Выбрать().
Да, типы возвращаются разные, но сам механизм и запросы, которые отправляются к БД? Возможно ли, что такая выборка порциями относится только к выборке при обращении к менеджеру объекта, или же с выборкой запроса механизм одинаковый?
Складывается ощущение, что я не правильно понял статью и под динамической выборкой подразумевается именно выборка из менеджера объекта, а не из результата запроса. Действительно, как, например, в сложном "навороченном" запросе выбрать строки с 25 по 50?
Коллеги, кто-то еще интересовался этим?
воскресенье, 4 августа 2013 г.
понедельник, 29 июля 2013 г.
одинес Портал
Ссылочка на память: http://portal.odines.ws/
Наблюдения, шаблончики, полезные рецепты, администрирование и прочее про 1С.
Наблюдения, шаблончики, полезные рецепты, администрирование и прочее про 1С.
пятница, 26 июля 2013 г.
С той стороны
hamster: если бы программисты были врачами, им бы пациенты говорили например "у меня болит нога", а они бы отвечали "ну не знаю, у меня такая же нога, а ничего не болит"bor
Номера субконто и "Выгрузить"
Недавно попался в одну хитрую ловушку, связанную с выгрузкой набора записей регистра бухгалтерии в таблицу значений.
Я использовал метод "Выгрузить" и обращался к субконто по номерам. А затем долго не мог понять, что за лажа происходит с моими субконто.
Оказывается нужно внимательнее читать синтакс-помощник:
Я использовал метод "Выгрузить" и обращался к субконто по номерам. А затем долго не мог понять, что за лажа происходит с моими субконто.
Оказывается нужно внимательнее читать синтакс-помощник:
Выгрузить (Unload)Черт возьми!
Синтаксис:
Выгрузить(<Строки>, <Колонки>)
...
Возвращаемое значение:
Тип: ТаблицаЗначений.
Описание:
Создает таблицу значений и копирует в нее записи набора. Структура полученной таблицы совпадает со структурой набора записей. Значения субконто выгружаются вместе с видами субконто. Для каждого субконто создается пара колонок с идентификаторами вида ВидСубконто<Номер>, Субконто<Номер>, для регистра не поддерживающего корреспонденцию, и ВидСубконтоДт<Номер>, СубконтоДт<Номер>, ВидСубконтоКт<Номер>, СубконтоКт<Номер>, для регистра поддерживающего корреспонденцию. При этом номера <Номер> могут не совпадать с номерами видов субконто на соответствующем счете.
среда, 24 июля 2013 г.
99 little bugs
99 little bugs in the code
99 little bugs in the code
Take one down, patch it around
117 little bugs in the code
from here
четверг, 18 июля 2013 г.
Мы и конфигуратор 8.3
Все чаще сталкиваюсь с платформой 8.3. Это и обсуждения на форумах и, конечно, pet projects.
Потихоньку "впитываю" все то, о чем писалось в анонсах и инф. письмах.
Вот то, чему я успел обрадоваться и попробовать в работе.
Смотрите, что теперь спрашивает конфигуратор при попытке создать обработчик события:
И какой код создает при выборе пункта "Создать на клиенте и процедуру на сервере":
Ну, не радость ли?
Глядя на следующее нововведение я смеялся и слезы счастья текли по моему лицу. Вот оно (нововведение, а не лицо):
Комментарии излишни. Кстати, работает еще и вот так:
Еще добавили новую сущность - определяемые типы. Вот так сразу оценить потенциал этого нововведения мне сложно, но чувствую, есть в этом шаг к полиморфизму:
И реквизит моего типа:
Это основное из того, что мне понравилось в использовании. Пишите мне о том, что понравилось вам. А я желаю вам хорошего дня и хорошего кода. До встречи.
Потихоньку "впитываю" все то, о чем писалось в анонсах и инф. письмах.
Вот то, чему я успел обрадоваться и попробовать в работе.
Смотрите, что теперь спрашивает конфигуратор при попытке создать обработчик события:
И какой код создает при выборе пункта "Создать на клиенте и процедуру на сервере":
Ну, не радость ли?
Глядя на следующее нововведение я смеялся и слезы счастья текли по моему лицу. Вот оно (нововведение, а не лицо):
Комментарии излишни. Кстати, работает еще и вот так:
Еще добавили новую сущность - определяемые типы. Вот так сразу оценить потенциал этого нововведения мне сложно, но чувствую, есть в этом шаг к полиморфизму:
И реквизит моего типа:
Это основное из того, что мне понравилось в использовании. Пишите мне о том, что понравилось вам. А я желаю вам хорошего дня и хорошего кода. До встречи.
среда, 17 июля 2013 г.
вторник, 16 июля 2013 г.
среда, 3 июля 2013 г.
Памятные даты
Сегодня руководитель проекта попросил заполнять нас тайм-шиты с получасовым интервалом.
Считается, что тайм-шит это инструмент, который помогает руководителю понять чем же на самом деле занимался программист в течение дня. Строгий и эффективный инструмент контроля, дающий объективную картину происходящего. =)
Но так же есть мнение, что программисты заполняют тайм-шиты "с потолка", а потому ценность таких бумаг примерно равна нулю.
Жаль, я не смог найти статью Тима Евграшина, посвященную тайм-шитам, там было несколько интересных выводов. А так же я не буду пытаться объять необъятное, и пытаться объективно оценить пользу от тайм-шитов со всех сторон, как в статье с хабра. Просто расскажу о нашей компании.
В нашей компании заполнение тайм-шитов не будет слишком эффективным.
Во-первых время в них никак не привязано к оплате. Если есть задача на 2 часа, то вне зависимости от того, сколько на нее потрачено времени по-факту (хоть сто), от этого ничего не изменится. Оплачены будут два часа, которые были поставлены заранее архитектором. Конечно, с архитектором можно поторговаться. Во общем, архитектор тоже человек и идет навстречу, но это все-равно означает, что решение об оплате зависит только от человеческого фактора и никак не формализовано, а уж тем более не связано с тайм-шитами.
И тут может возникнуть двойственная ситуация. Ежедневно руководитель/архитектор молча принимает тайм-шиты, как бы говоря - "да, все хорошо, ты занимался этой задачей, я вижу твой зафиксированный факт и верю ему", а когда дело доходит до расчетов, тайм-шиты аннулируются и в расчет берется плановая цифра, которая, естественно, меньше фактической.
Из этого вытекает вторая проблема. Обычный разработчик не понимает зачем ему вообще заполнять тайм-шиты. На оплату они никак не влияют, на другие метрики тоже. И вообще не факт, что их вообще читают. Узнать об этом нет никакой возможности, поскольку никакой обратной связи по тайм-шитам не поступает, кроме требования ежедневно их заполнять. Т.е. тайм-шит превращается для разработчика в некий управленческий артефакт, замкнутый сам на себя. В нечто, что просто требуется делать не вдумываясь в суть происходящего.
В большей своей массе программисты умные люди и не любят делать того, чего они не понимают. Из этого вытекает третья проблема. Сомнительная достоверность тайм-шитов. Во-первых отношение. То, что нужно непонятно для чего, можно сделать абы-как. Тайм-шит высасывается из пальца с таким расчетом, чтобы он выглядел "средне", показывал, что во общем программист работает над задачей. Никакой точной метрики с получасовой дискретой из него не вытащишь. Попытка же проконтролировать каждые пол часа или даже час приведет к микроменеджменту. А эта идея, как уже давно известно, провальная.
Вот три основных момента, которые будут мешать нормальной работе тайм-шитов, так, как она обычно представляется.
Кроме того, сейчас я обратил внимание на то, что план работ, который необходимо предоставить утром так же должен быть расписан с получасовой дискретой. Не всегда просто для программиста сказать, в какие пол часа он будет заниматься кодом какой процедуры. Для факта это можно отмониторить, но для плана предсказать достаточно тяжело.
Закончить хотелось бы фразой из Голдрата -
Желаю вам хорошего дня и хорошего кода. А я пойду подготовлю себе шаблончиков для тайм-шитов с получасовой дискретой, посмотрим чем это закончится.
Кроме того, сейчас я обратил внимание на то, что план работ, который необходимо предоставить утром так же должен быть расписан с получасовой дискретой. Не всегда просто для программиста сказать, в какие пол часа он будет заниматься кодом какой процедуры. Для факта это можно отмониторить, но для плана предсказать достаточно тяжело.
Закончить хотелось бы фразой из Голдрата -
"Учёт затрат - самый большой враг продуктивности!"
Желаю вам хорошего дня и хорошего кода. А я пойду подготовлю себе шаблончиков для тайм-шитов с получасовой дискретой, посмотрим чем это закончится.
Мнение выраженное в этом сообщении является частным мнением и может не совпадать с официальной позицией компании.
Подписаться на:
Сообщения (Atom)