Как стать автором
Обновить
27.1
Карма
0
Рейтинг
Сергей @altern

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

Управления конфигурационными файлами в .net проектах

Самый простой способ избежать конфликтов в конфигурационных файлах — это хранить шаблон конфигурационного файла в системе контроля версий. Например, если приложение использует файл db.properties, то в системе контроля версий должен храниться файл db.properties.tmpl. При первой загрузке изменений из системы контроля версий (update, pull, etc) каждый разработчик переименовывает .tmpl файл избавляясь от расширения (так как приложение использует db.properties, без наличия этого файла ничего работать не будет) и заодно подставляя нужные ему значения конфигурации. При последующих обновлениях шаблона конфигурационного файла каждый разработчик будет видеть что добавились новые параметры и что нужно добавить соответсвующие декларации в свой конкретный конфигурационный файл при этом подставив нужные значения.

Как положить спасибо в карман

Хотел бы я иметь возможность променять FogCreek на Google… Это прям как Mercedes поменять на BMW.

Simplify.js — JavaScript-библиотека для упрощения ломаных линий

> ты забыл, что JavaScript теперь активно используется и на сервере.
я и вправду забыл. все вопросы снимаются)

Simplify.js — JavaScript-библиотека для упрощения ломаных линий

Я не могу придумать применение (помимо картографии) огромному массиву точек, визуализацию которого нужно упрощать. Разве подобного рода упрощение не происходит на server-side? Не думаю что имеет смысл гонять кучу данных (координаты точек) от сервера к клиенту для того, чтобы уже на клиенте минимизировать количество визуализированных точек.

Simplify.js — JavaScript-библиотека для упрощения ломаных линий

Мне вдруг стало интересно каковы возможные применения помимо картографии. Видимо стоило быть поконкретней.

Simplify.js — JavaScript-библиотека для упрощения ломаных линий

И каковы возможные применения?

Мифы о CMMI, или кому и зачем она нужна

Спасибо за исчерпывающий ответ!

Мифы о CMMI, или кому и зачем она нужна

Отличная статья! Поражает невежество и, своего рода, потребительский подход комментаторов — всё разжевывать нужно.

Со своей стороны есть несколько комментариев/вопросов.

1. Результаты анализа данных о прошедших (с 2006 г.) оцениваниях относительно модели CMMI, опубликованные SEI в сентябре 2011, показывают, что 66% оцениваний проведены в компаниях категории «1-100 человек», при этом внутри этой категории главные подкатегории «25 и менее» и «26-50». Сложно поверить в то, что небольшие компании могут обладать высокими уровнями CMMI. Насколько я понял из пояснения к первому мифу, достаточно высок процент небольших компаний, обладающих каким либо уровнем зрелости. Интересно было бы подробнее узнать, какие это уровни. Не уверен что коллективу из 50 человек может быть нужен 4-й уровень, а если даже и нужен, то непонятно как этот уровень в естесственных (не навязанных заказчиком, менеджментом, еще кем либо) условиях может поддерживаться — компания и ее сотрудники должны обладать высокой культурой ведения IT-бизнеса и хорошим пониманием процессов. Или, другими словами, все 50 человек включая девушку на ресепшне — это монстры своего дела, а о сотрудниках-джуниорах не может идти даже речи. Это при всём том, что для большинства процессных задач можно найти нужные и эффективные инструменты. Если большинство компаний небольшого размера имеют уровень не выше 3-го, тогда вопрос снимается. Вообщем, очень интересно было бы посмотреть на статистику.

2. Из практики (и из Agile Manifesto): несмотря на все желание быть Agile и работать с заказчиком ну очень близко, наша компания, обжегшись, все же взялась за усиление контрактной составляющей сотрудничества.
Не совсем понятно зачем понадобилось усиление контрактной составляющей. Неужели для того, чтобы заставлять заказчика что-то делать в соответствии с выстроенными процессами? :) Если заказчик хочет одновременно agile и cmmi, то он должен понимать что это серьезный коммитмент в интересах качества, а также иметь в виду усилия, которые со своей стороны нужно прикладывать. Если же в компании cmmi, a заказчик хочет agile и нужно их как-то подружить, то ОЧЕНЬ много зависит от адекватности заказчика. Часто слишком много усилий уходит для того, чтобы объяснить, почему процесс построен так, а не иначе. Я бы не стал предлагать/навязывать свои процессные модели заказчику если он не способен безболезненно в эти модели интегрироваться. А контрактные обязательства — это не всегда безболезненно.

3. CMMI будет оправдывать ожидания (и затраченные средства), если компания продает solution, управляет процессом удовлетворения бизнес потребностей клиента.
Интересно было бы узнать о практике применения CMMI для аутсорсинга. Ведь есть отдельный раздел — CMMI for Acquisition, ориентированный на это. Так что не совсем обязательно, что CMMI аппрайзал не может быть использован для повышения эффективности аутсорсинговых компаний. Согласен с тем, что это несколько сложнее. Но если заказчик хочет и готов к сотрудничеству в этом направлении, то выстроить процессы может оказаться даже проще, чем для продуктовой компании.

Java-кодерам посвящается

Подругу для съемок выбрали очень даже зачетную :) Really hot!

Субъективно о медиа-центре E-Great M32B

А как насчет интеграции с lastfm?

Ну и интересно по поводу проигрывания музыки и подключения сносной акустической системы

Модель CMMI

То есть, проще говоря, нужно иметь CMP (Configuration Management Plan). Этого достаточно? Всё перечисленное можно втиснуть в рамки этого документа. Но мне всё таки интересно, есть ли требования CMMI к тому, что конкретно должно быть обязательно включено в CMP. Ведь сами по себе практики конфигурационного менеджмента вроде как опциональны. Кроме контроля версий стандарт требует наличие каких-то практик? Если да, то каких? Насколько глубоко описываются требования к использованию контроля версий и вообще специфицируется ли то, что же конкретно такое контроль версий?

Инструменты css, экономящие ваше время

В избранное. Сам пользуюсь YAML-builder, очень доволен

Модель CMMI

Обязательно пишите про механику внедрения по возможности. Лично мне будет интересно.

И еще хотелось бы узнать как же конкретно CMMI относится к конфигурационному менеджменту? Предъявляются ли какие-то требования к процессам конфигурационного менеджмента или он просто «должен быть»? Насколько я знаю, в CMMI не предъявляется жетских требований к необходимости использования, к примеру, контроля версий. Если так, то как тогда как CMMI предлагает осуществлять конфигурационный менеджмент? Ведь контроль версий — это его основной процесс. С другой стороны я понимаю что CMMI не должен опускаться до таких деталей, но, тем не менее, всё равно интересно насколько детализированы/абстрактны описания высоких уровней зрелости.

Конфигурационный менеджмент (часть 2, обзор инструментов)

слово «отслеживание» менее употребимо (ну не звучит и всё тут) в русском языке чем «контроль», да и «контроль» смысл передает лучше.

Конфигурационный менеджмент (часть 2, обзор инструментов)

Вообще, говоря о «контроле постановки задач», я имею в виду не конкретную систему(-ы), а деятельность (или процесс).

О Smalltalk в России

Ну и вообще хотел комментариев по поводу того, что Smalltalk мертв, с чего бы это и как так могло получиться.

О Smalltalk в России

Извините, действительно не очень уместо вот так давать ссылку без комментариев. Хотел узнать ваше мнение по поводу того, что в smalltalk «it's too easy to make a mess». Действительно ли это так и насколько тесно можно провести паралели между Ruby и Smalltalk?

Конфигурационный менеджмент (часть 2, обзор инструментов)

я имел в виду issue tracking. как насчет присутствия enhancement в issue tracking system, в этом случае она все еще «система отслеживания дефектов»?
употребление «баг-трекер» для описания bug-tracker'ов мне кажется вполне допустимым :)

О Smalltalk в России

What killed Smalltalk and could kill Ruby too: railsconf.blip.tv/file/2089545/

Конфигурационный менеджмент (часть 2, обзор инструментов)

«контроль постановки задач» — это неправильно? буду рад если вы приведете пример более употребляемого словосочетания. искал искал — не нашел

ну и вроде как я не отождествляю bug tracking и issue tracking, а наоборот — разграничиваю. кстати, по тем же причинам, на которые вы указали: баг трекер — частный случай

Информация

В рейтинге
5,823-й
Откуда
Киев, Киевская обл., Украина
Дата рождения
Зарегистрирован
Активность