http://wordrive.com/~59
Способ оформления ссылки, чтобы занимала меньше места и несла информацию о номере фразы. Чем выше основа системы счисления, тем меньше знаков нужно для выражения айдишника. 59 в 62-ричной системе — 319. 1 000 000 — это «4c92» в 62-ричной. То есть на много миллионов хватит четырех знаков. Конечно, дополнительно еще можно несложно шифровать, у меня пока этого нет за ненадобностью.
На мой взгляд, правильнее советовать менеджеру работать так, чтобы завтра этот менеджер стал выше, чтобы ему доверять более крупные и ответственные проекты. Для этого он должен постоянно думать, как слить с себя то, что мешает этому. Например, менеджер проекта в какой-то момент начинает осознавать, что быть единственным контактом для клиента на все случаи жизни может и удобно для клиента, но явно ступор для него. Через месяц клиенты уже привыкли общаться с техсаппортом, а менеджер ведет проект крупнее. Если он бы научился заменять шестерых саппортеров, его бы ценили, но он бы не смог сменить масштаб.
не совсем прикинуть.
в компаниях, где внедрено бюджетирование, в декабре нужно на год вперед расписать ФОТ по отделу с конкретными цифрами. В принципе, конечно, можно с чистого листа все сделать — собрать все зарплаты, прикинуть, кто нужен еще, округлить циферки и это выдать. Но получится одноразовый документ, с которым потом сложно работать в течение года. Важно еще уметь объяснить, откуда они берутся, потому что в 9 из 10 случаев вас спросят «Почему так много?» и нужно аргументировано защищать. Поэтому важно иметь такой документ, в котором можно быстро пересмотреть численность тестировщиков и сразу получить итоговые цифры, потому что в том торг между теми, кто дает деньги и теми, кто их тратит на персонал)
Project — инструмент для управления проектами, а не процессом разработки.
Следовательно, там все заточено под проект. К примеру, для того, чтобы задачи занимали последовательно время исполнителя, в прожекте нужно называть именами исполнителей группы задач, а все задачи подгруппы связывать в цепочку. Если этого не делать, то равномерно занять разработчика будет очень непросто, когда задач много и они постоянно двигаются. Но при этом же нужно указывать исполнителя внутри задачи, как свойство, чтобы можно было, например, рассчитывать загрузку или группировать по проектам. В итоге одно и то же указывается в двух местах. Если переносишь задачу с Иванова на Петрова, нужно кроме того, что ее в другую группу переносить, еще и в свойствах исправлять. Плюс непросто разбивать задачу на кусочки, например, начинаем сейчас, потом бросаем, потом вспоминаем. Там постоянно рушатся связи, там непросто сделать выборки — например, по клиентам, непросто отслеживать изменения (есть Baseline, но с ним в условиях постоянных перестановок можно повеситься). Мне было бы интересно почитать, кто его использует для этих задач, может там хитрости какие есть, а я про них не знаю. Сам прожект, вроде бы, довольно глубоко знаю.
Ну и напоследок — Microsoft Project, вообще-то, коммерческий продукт. Лицензия, кажется, стоит тысяч 15 на одно рабочее место. Если уж выбирать среди коммерческих продуктов, там выбор сразу появляется. Но главное — он не для этого придуман, он под проекты заточен, а не под процесс.
Хе, так это у него всегда такое, когда ему приходится умещаться в дозволенные эфиром «цензурные и культурные рамки».
В данном случае ведущему имело смысл, кстати, их не ставить — подкаст бы получился сильно интереснее, но, боюсь, половина слушателей меня не поддерживает :)
Потому что сишные функции, используемые для работы со строками, не понимают многобайтных строк. А там много что было построено на стандартных strlen, strstr и прочего добра для того, чтобы быстро работало. Переделать можно было (на всякие mb_strlen, на классы), но много было переделывать. Вот что значит — непродумали изначально. Впрочем, это не сильно мешало: создания многоязыковых систем тогда в проектах не было вообще.
Мне кажется, это вы про свой софт. А когда заглядываешь в уже сделанное кем-то ранее, удивляет, почему там иначе. Вот в продукте, который достался в прошлом году мне — иначе. Не буду оглашать компанию-разработчика, там уже из тех программеров давно никого не осталось.
Прекрасный подход :) Можно лепить из глины кусочек за кусочком, а можно — взять большое глиняное бревно и поубирать все лишнее. Отличное задание на собеседование — сделать работающий код лучше. Можно взять буквально любой модуль и отдать на трепанацию и обрезание. По крайней мере, скажет о человеке ничуть не меньше, чем модуль, заново им написанный.
1. К COM претензии только в одном — за рамки мира windows он не выходит. Внутри windows вполне себе технология. Я cobra ругаю, а не com.
2. Про узкое применение — я имел ввиду для межпрограммного взаимодействия в однородной майкрософтовской среде. Например, свою почтовую службу, работающую на юниксе, я по COM Ник чему не подключу. А по SOAP, например, вполне. Хотя, конечно, это не совсем сравниваемые вещи.
3. Юниксовое связывание используется на несколько порядков активнее, чем виндовое COM. Потому что его используют не только 'родные' компонеты ОС, но и 90% программ на sourceforge. Поэтому с windows powershell сравнивать плохо.
У нас тут был великолепный опыт разработки на windows script engine. я сейчас с айпада пишу — неудобно, если Макс вылезет, буду ему признателен за примеры. Это вообще чудо какое-то, а не инструмент. Хотя не совсем в тему.
я сервера имел ввиду, конечно. Если программно-аппаратное решение разрабатывается, там подход, конечно, должен учитывать требования к производительности, энергопотреблению, теплоотдаче и многому другому… Там тонкостей вообще до фига. А для сайтов-сервисов лучше добавить еще один (два, пять) сервера, зато иметь красивую и прозрачную архитектуру, чем оптимизировать донельзя, чтобы потом любое изменение было целым проектом… Я тут недавно с одними людьми общался, руководителями интернет-магазина, так у них он развернут, по его словам, на сорока серверах. Мне вообще очень сложно представить, что же там такое должно быть, чтобы не хватило 2-4 серверов. Но для 2-4 серверов написать софт, способный перерабатывать несколько миллионов хитов очень непросто. Поэтому обычно такие магазины ставят на 5-8 серверов и их достаточно по уши (у нас осенью так будет). Так вот, если есть выбор — оптимизировать ПО в ущерб архитектурной целостности и supportability, в ущерб стоимости поддержки и развития, или добавить пару серверов и ничего не трогать, то лучше выбрать второе. А трогать уже без спешки — проводить рефакторинг, взвешивая каждое изменение.
Способ оформления ссылки, чтобы занимала меньше места и несла информацию о номере фразы. Чем выше основа системы счисления, тем меньше знаков нужно для выражения айдишника. 59 в 62-ричной системе — 319. 1 000 000 — это «4c92» в 62-ричной. То есть на много миллионов хватит четырех знаков. Конечно, дополнительно еще можно несложно шифровать, у меня пока этого нет за ненадобностью.
;-)
в компаниях, где внедрено бюджетирование, в декабре нужно на год вперед расписать ФОТ по отделу с конкретными цифрами. В принципе, конечно, можно с чистого листа все сделать — собрать все зарплаты, прикинуть, кто нужен еще, округлить циферки и это выдать. Но получится одноразовый документ, с которым потом сложно работать в течение года. Важно еще уметь объяснить, откуда они берутся, потому что в 9 из 10 случаев вас спросят «Почему так много?» и нужно аргументировано защищать. Поэтому важно иметь такой документ, в котором можно быстро пересмотреть численность тестировщиков и сразу получить итоговые цифры, потому что в том торг между теми, кто дает деньги и теми, кто их тратит на персонал)
Ну это мое мнение, у всех по-разному, конечно.
Следовательно, там все заточено под проект. К примеру, для того, чтобы задачи занимали последовательно время исполнителя, в прожекте нужно называть именами исполнителей группы задач, а все задачи подгруппы связывать в цепочку. Если этого не делать, то равномерно занять разработчика будет очень непросто, когда задач много и они постоянно двигаются. Но при этом же нужно указывать исполнителя внутри задачи, как свойство, чтобы можно было, например, рассчитывать загрузку или группировать по проектам. В итоге одно и то же указывается в двух местах. Если переносишь задачу с Иванова на Петрова, нужно кроме того, что ее в другую группу переносить, еще и в свойствах исправлять. Плюс непросто разбивать задачу на кусочки, например, начинаем сейчас, потом бросаем, потом вспоминаем. Там постоянно рушатся связи, там непросто сделать выборки — например, по клиентам, непросто отслеживать изменения (есть Baseline, но с ним в условиях постоянных перестановок можно повеситься). Мне было бы интересно почитать, кто его использует для этих задач, может там хитрости какие есть, а я про них не знаю. Сам прожект, вроде бы, довольно глубоко знаю.
Ну и напоследок — Microsoft Project, вообще-то, коммерческий продукт. Лицензия, кажется, стоит тысяч 15 на одно рабочее место. Если уж выбирать среди коммерческих продуктов, там выбор сразу появляется. Но главное — он не для этого придуман, он под проекты заточен, а не под процесс.
В данном случае ведущему имело смысл, кстати, их не ставить — подкаст бы получился сильно интереснее, но, боюсь, половина слушателей меня не поддерживает :)
2. Про узкое применение — я имел ввиду для межпрограммного взаимодействия в однородной майкрософтовской среде. Например, свою почтовую службу, работающую на юниксе, я по COM Ник чему не подключу. А по SOAP, например, вполне. Хотя, конечно, это не совсем сравниваемые вещи.
3. Юниксовое связывание используется на несколько порядков активнее, чем виндовое COM. Потому что его используют не только 'родные' компонеты ОС, но и 90% программ на sourceforge. Поэтому с windows powershell сравнивать плохо.
У нас тут был великолепный опыт разработки на windows script engine. я сейчас с айпада пишу — неудобно, если Макс вылезет, буду ему признателен за примеры. Это вообще чудо какое-то, а не инструмент. Хотя не совсем в тему.