Можно, но мне удобнее LinqToSql пока. Там далее в разделе скаффолдинга мы автоматизируем процесс создания репозитория. Я пробовал использовать и Code First, по сути там нужны минимальные изменения. Я думаю, потом допишу по этой теме и реализацию с Code First.
— Можно закладывать и 200% процентов, но попробуйте найти заказчика с такими ценами.
А уменьшить себестоимость на 25% или 50% соответственно?
— 4 месяца проект не делается. По расчету он делается один месяц и растягивается на 4 в случае наличия проблем в проекте.
— Проект проваливается очень быстро, а вот тянется он долго (если усреднить, то в 4 раза дольше чем делается)
Тут вопрос занятости. Например, вы начали разрабатывать проект и через 3 недели показали заказчику. В этот момент заказчик или говорит: «Ой не! Всё фигня!» и тут два пути, или он дает предоплату (что покрывает уже часть расходов) и вы продолжаете работать. Или не платит и вы в мусорное ведро выкидываете проект.
Мои принципы — это:
очень внимательно следить за своими словами
пресекать неясности с дополнительными хотелками клиента
не бояться выкинуть проект
Например, если фактический расход уже превышает стоимость проекта (съедает всю прибыль), то проанализировать куда потрачено столько ресурсов. После этого, при дальнейшей разработке регистрировать каждый чих сделанный в сторону этого проекта. Можно заморозить проект на месяц, сделать быстро прибыльный за это время.
Рассматривать всегда каждый проект, как единственный, который у вас есть. Например, если я работаю только над одним проектом, то работая в убыток я не протяну 4 месяца. Мои ресурсы слишком ограничены чтобы тянуть эту лямку дальше. Мое поведение будет в крайней степени зависеть от этого, будет вполне логичным и для клиента.
Вообще-то расчеты и выводы по крайней мере странные.
Во-первых, если закладывать прибыль на 100% от себестоимости, то можно и два провальных проектов иметь и выходить в ноль, что в принципе уже является принципом безубыточности и во многих отраслях это является хорошим признаком.
Во-вторых, четыре месяца делать проект не фиксируя поэтапную оплату, даже хуже, не беря предоплату — это в какой такой волшебной стране?
В-третьих, «проваливать» проект 4 месяца — это всё-таки ни в какие ворота. Или над этим проектом работают люди далекие от разработки, и надо делать чистки в рядах. Или этот проект не по силам пока студии, но является по каким-то причинам приоритетными и эти убытки можно списывать на ивестиции в более светлое будущее.
Какие-то взятые с потолка цифры не описывают всей ситуации и выводы тут:
Делай, что уже умеешь. Что не умеешь делать, за то не берись.
Скорость важнее всего.
Лучше много мелких проектов, чем несколько больших.
Переложите вашу эффективность на плечи заказчика используя почасовую оплату.
Работая у вас менеджером и руководствуясь такими принципами я бы отбирал проекты для студии максимально типичные и максимально простые, которые по сути уже готовы. Высылал бы ТЗ максимально шаблонизированное, т.е. по сути поменять названия и всё. При попытке клиента заказать что-то определенно другое, действовал бы поэтапно. Вначале, попытки склонить к существующему варианту. При неудаче, обозвать этот проект уникальным и, взвинтив ценник, предложить почасовую оплату. Клиент или отвалится, или закабалится.
Ошибка в том, что HeatingFactory на выходе выдает что-то такое абстрактно нагревающее (AbstractHeatingSmth), что непонятно как включать? Т.е. без известных методов?
Да, и я в этой истории на стороне Бориса, как ни странно, в его ахритектуре больше информации. Да, немного с избытком. Чтобы навести порядок в его коде — достаточно будет 30 минут вдумчивого чтения, и да — любую часть покрыть тестами, выборочно.
Чтобы проверить код Маркуса для начала необходим будет сам Маркус, причем достаточно свежий. Который сможет по номерам сказать какой тип булочки под номером 4, и какой тип печи под номером 3, потому что это не очевидно. Отрефакторить такое сложнее чем кажется. И как показывает практика — переписывать никогда не успевается. Стартапы так и гибнут, когда старый код начинает пахнуть, а ПМ хочет новых безумных фишек.
На самом деле очень просто. Указываешь свою страницу на фрилансе, и как дополнительно задаешь уникальную фразу, которая не привлечет внимание (Например: «Беру заказы на начало следующего года»).
Шаг 1.
Проверка сервером. В статусе этой фразы нет — ОК
Шаг 2.
Меняешь статус на эту фразу.
Шаг 3.
Проверка сервером. В статусе эта фраза есть — ОК
Шаг 4.
Опционально. Меняешь на первоначальный статус.
Идентификация пройдена, и даже автоматически делается на раз… И никаких контактов, скайпов и телефонов.
Немного опасно.
Моего контакта там нет, хотя я на фрилансе уже лет шесть. Якобы мой контакт смогут добавить мошенники и выдать себя за меня. Хотя я никакого отношения к этому уже иметь не буду. Ну и кинут кого-то.
Ну видимо есть опасения, что эту нишу без дополнительного финансирования не удержать. Например bitbucket предлагает как git так и mercurial репозитории, и по вполне конкурентным ценам (1000$ в год за анлим аккаунт).
Не надо думать, что компания жмется на нормальный офис. Т.е. как бы ситуация, мы имеем годовой оборот в миллиарды рублей, но сидим в опен-спейсе, потому что лишний доллар за кв.м аренды в месяц — это накладно.
Я начальник, что я хочу получать:
— масштабируемость. Получил новый проект, подписал договор, нанял и посадил еще +4 программиста и +2 тестера.
— гибкость. Пересадил этого с этим, а тех дополнил вот этим.
— городская инфраструктура. Лучше в хорошей доступности (в некоторых городах офисные центры имеют большую ценность, если от них можно быстро доехать из пригорода и аэропорта), чем кабинеты в жопе географии, где каждому добравшемуся курьеру аплодируют стоя.
— доступность общей информации. Быстрый и исчерпывающий обмен информации, взаимное обучение возрастает, так как быстрая обратная связь. Послал имейл, а тебе через сутки: «извини, я что-то ничего не понял». При личном общении такое маловероятно, по глазам видно, поняли тебя или нет.
— открытость с коллегами (не «эти курицы из бухгалтерии»).
— играть в КС в опен-спейсе в обеденное время при нормальной дисциплине даже в голову не придет. А это даже не контроль, это physical framework — т.е. влияние среды на поведение.
Ок. Что же по поводу творчества? Разница между «дом — опен-спейс» и «кабинет — опен-спейс» в первом случае больше. Больше комфорта. Я сам работаю дома. Кабинет может быть даже хуже опен-спейса, посадят с каким-то гением C++ сидящего в свитере благоухающего прошлогодним табаком или чем похуже. Тут-то вообще не поработаешь.
Скорее всего мы просто смотрим с разных сторон на этот опен-спейс. Вы как на воплощение антиутопичных оурелловских интерьеров, где столы в ряд, и ходят строем и большой брат вещает из такого большого телевизора. Ужас, конечно.
В моем же сознании картина рисуется совсем другая:
Программист, сидевший вчера до 3 ночи, к 14 приезжает на работу на новом велике, не вытаскивая наушники, орет всем «Привет, коллеги!» отчего менеджер уже час следящий за хитрой мыслью англоязычного заказчика вздрагивает с мыслью «убью мудака». Программист демонстрирует новую раму, подтягиваются заинтересовавшиеся, все решают стоила ли покупка денег. Шум, гам. А я в этой картине тот его начальник, который только что написал продакт менеджеру, что наше чудо прибыло и может быть счас поправит вчерашние баги и выложит коммит.
Опен-спейс — это общее пространство, мы обязаны подчинятся общим правилам. На улице мы стаем в очередь, не перепрыгиваем через турникеты, не занимаем правый ряд, если едем прямо, и не стоим, а идем на эскалаторе слева. Это общие правила, там есть штрафы и запреты, как-то не проезжать на красный свет, но никто не говорит «мы проводим на улице много времени, я хочу делать все что хочу».
1. Выдать всем наушники
2. Запретить громко говорить в опен-спейсе (повесить картинки типа «не шуми, программист спит»)
3. С мобильником — пусть ходят на кухню\в переговорку
3. Выделить кабинет для обсуждения\митингов, где в свободное время менеджеры могут вести свои беседы по скайпу.
4. Перестать здороваться, или хотя бы ввести правило, что после начала рабочего времени — надо входить тихо и застенчиво дабы не быть оштрафованым за опоздание.
5. Хочет менеджер обсудить что-то с 2мя и более людьми — создает встречу в оутлуке, и тихо все сваливают в переговорку или на кухню.
Всё ок, только не надо забывать про использование area в asp.net mvc. Т.е. я могу создать два одинаковых контроллера с двумя одинаковыми экшнами, но в разных area. Например: Admin/Home/Index, Default/Home/Index, где первый для админа, а второй для всех.
Так вот тут
public class DynamicAuthorizeAttribute : FilterAttribute, IAuthorizationFilter
{
public void OnAuthorization(AuthorizationContext filterContext)
{
...
string area = filterContext.RouteData.DataTokens["area"] as string;
....
}
А уменьшить себестоимость на 25% или 50% соответственно?
Тут вопрос занятости. Например, вы начали разрабатывать проект и через 3 недели показали заказчику. В этот момент заказчик или говорит: «Ой не! Всё фигня!» и тут два пути, или он дает предоплату (что покрывает уже часть расходов) и вы продолжаете работать. Или не платит и вы в мусорное ведро выкидываете проект.
Мои принципы — это:
Например, если фактический расход уже превышает стоимость проекта (съедает всю прибыль), то проанализировать куда потрачено столько ресурсов. После этого, при дальнейшей разработке регистрировать каждый чих сделанный в сторону этого проекта. Можно заморозить проект на месяц, сделать быстро прибыльный за это время.
Рассматривать всегда каждый проект, как единственный, который у вас есть. Например, если я работаю только над одним проектом, то работая в убыток я не протяну 4 месяца. Мои ресурсы слишком ограничены чтобы тянуть эту лямку дальше. Мое поведение будет в крайней степени зависеть от этого, будет вполне логичным и для клиента.
Во-первых, если закладывать прибыль на 100% от себестоимости, то можно и два провальных проектов иметь и выходить в ноль, что в принципе уже является принципом безубыточности и во многих отраслях это является хорошим признаком.
Во-вторых, четыре месяца делать проект не фиксируя поэтапную оплату, даже хуже, не беря предоплату — это в какой такой волшебной стране?
В-третьих, «проваливать» проект 4 месяца — это всё-таки ни в какие ворота. Или над этим проектом работают люди далекие от разработки, и надо делать чистки в рядах. Или этот проект не по силам пока студии, но является по каким-то причинам приоритетными и эти убытки можно списывать на ивестиции в более светлое будущее.
Какие-то взятые с потолка цифры не описывают всей ситуации и выводы тут:
Работая у вас менеджером и руководствуясь такими принципами я бы отбирал проекты для студии максимально типичные и максимально простые, которые по сути уже готовы. Высылал бы ТЗ максимально шаблонизированное, т.е. по сути поменять названия и всё. При попытке клиента заказать что-то определенно другое, действовал бы поэтапно. Вначале, попытки склонить к существующему варианту. При неудаче, обозвать этот проект уникальным и, взвинтив ценник, предложить почасовую оплату. Клиент или отвалится, или закабалится.
Да, и я в этой истории на стороне Бориса, как ни странно, в его ахритектуре больше информации. Да, немного с избытком. Чтобы навести порядок в его коде — достаточно будет 30 минут вдумчивого чтения, и да — любую часть покрыть тестами, выборочно.
Чтобы проверить код Маркуса для начала необходим будет сам Маркус, причем достаточно свежий. Который сможет по номерам сказать какой тип булочки под номером 4, и какой тип печи под номером 3, потому что это не очевидно. Отрефакторить такое сложнее чем кажется. И как показывает практика — переписывать никогда не успевается. Стартапы так и гибнут, когда старый код начинает пахнуть, а ПМ хочет новых безумных фишек.
Шаг 1.
Проверка сервером. В статусе этой фразы нет — ОК
Шаг 2.
Меняешь статус на эту фразу.
Шаг 3.
Проверка сервером. В статусе эта фраза есть — ОК
Шаг 4.
Опционально. Меняешь на первоначальный статус.
Идентификация пройдена, и даже автоматически делается на раз… И никаких контактов, скайпов и телефонов.
Моего контакта там нет, хотя я на фрилансе уже лет шесть. Якобы мой контакт смогут добавить мошенники и выдать себя за меня. Хотя я никакого отношения к этому уже иметь не буду. Ну и кинут кого-то.
© баша
Я начальник, что я хочу получать:
— масштабируемость. Получил новый проект, подписал договор, нанял и посадил еще +4 программиста и +2 тестера.
— гибкость. Пересадил этого с этим, а тех дополнил вот этим.
— городская инфраструктура. Лучше в хорошей доступности (в некоторых городах офисные центры имеют большую ценность, если от них можно быстро доехать из пригорода и аэропорта), чем кабинеты в жопе географии, где каждому добравшемуся курьеру аплодируют стоя.
— доступность общей информации. Быстрый и исчерпывающий обмен информации, взаимное обучение возрастает, так как быстрая обратная связь. Послал имейл, а тебе через сутки: «извини, я что-то ничего не понял». При личном общении такое маловероятно, по глазам видно, поняли тебя или нет.
— открытость с коллегами (не «эти курицы из бухгалтерии»).
— играть в КС в опен-спейсе в обеденное время при нормальной дисциплине даже в голову не придет. А это даже не контроль, это physical framework — т.е. влияние среды на поведение.
Ок. Что же по поводу творчества? Разница между «дом — опен-спейс» и «кабинет — опен-спейс» в первом случае больше. Больше комфорта. Я сам работаю дома. Кабинет может быть даже хуже опен-спейса, посадят с каким-то гением C++ сидящего в свитере благоухающего прошлогодним табаком или чем похуже. Тут-то вообще не поработаешь.
В моем же сознании картина рисуется совсем другая:
Программист, сидевший вчера до 3 ночи, к 14 приезжает на работу на новом велике, не вытаскивая наушники, орет всем «Привет, коллеги!» отчего менеджер уже час следящий за хитрой мыслью англоязычного заказчика вздрагивает с мыслью «убью мудака». Программист демонстрирует новую раму, подтягиваются заинтересовавшиеся, все решают стоила ли покупка денег. Шум, гам. А я в этой картине тот его начальник, который только что написал продакт менеджеру, что наше чудо прибыло и может быть счас поправит вчерашние баги и выложит коммит.
Опен-спейс — это общее пространство, мы обязаны подчинятся общим правилам. На улице мы стаем в очередь, не перепрыгиваем через турникеты, не занимаем правый ряд, если едем прямо, и не стоим, а идем на эскалаторе слева. Это общие правила, там есть штрафы и запреты, как-то не проезжать на красный свет, но никто не говорит «мы проводим на улице много времени, я хочу делать все что хочу».
2. Запретить громко говорить в опен-спейсе (повесить картинки типа «не шуми, программист спит»)
3. С мобильником — пусть ходят на кухню\в переговорку
3. Выделить кабинет для обсуждения\митингов, где в свободное время менеджеры могут вести свои беседы по скайпу.
4. Перестать здороваться, или хотя бы ввести правило, что после начала рабочего времени — надо входить тихо и застенчиво дабы не быть оштрафованым за опоздание.
5. Хочет менеджер обсудить что-то с 2мя и более людьми — создает встречу в оутлуке, и тихо все сваливают в переговорку или на кухню.
Так вот тут
Ну и проверять соответственно.