Уровень подготовки читателя: низкий — средний. Вот список вещей, которые вы должны иметь в виду на ранних стадиях создания стартапа, составленный по мотивам набитых шишек. Продукт: ваш продукт должен быть обезболивающим, а не витаминами. Убедитесь, что он решает проблемы или удовлетворяет потребности. Он не должен быть чем-то, необходимость чего вам каждый раз приходится объяснять, ссылаясь на какие-нибудь основные тренды рынка. Продукт должен быть очевиден и должен описываться одним предложением. Если у вас не так — вы проиграли еще не начав. Убедитесь, что ваша целевая аудитория может быстро и легко с точки зрения юзабилити погрузиться в процесс опробования. Позаботьтесь о том, чтобы работа с продуктом давала мгновенное вознаграждение, вызывала привязанность и желание вернуться за новыми впечатлениями. Избегайте изменяющегося ценообразования, напрямую зависящего от использования каждой функции продукта (хотя и не стоит понимать это слишком буквально). Маркетинг: встройте маркетинг в свой продукт. Термин «вирусный маркетинг» часто используется неверно. Людская молва это хорошо, но это не вирус. Вирус это что-то, что распространяется само по себе, поскольку оно используется или случается. Вспомните о человеке из вашего офиса, который «одарил» вас простудой прошлой зимой — вот это вирусность. Избегайте оплаты за каждого нового клиента или, по крайней мере, сведите её к минимуму. Если одурачивать себя неестественными метриками, это скажется на вас. Тем не менее, поддерживайте небольшой маркетинговый бюджет на брендинг и PR; бдительность пригодится вам в переломный момент. Финансы: отдавайте в аутсорсинг так долго, как сможете. В первые дни это не критично, но должно учитываться. Бухгалтер на аутсорсинге испытывает гордость от прикрытия собственной задницы, используйте это. Если вы наняли кого-то на полный день слишком рано, вы рискуете получить мнение, что этот путь слишком консервативен на данном этапе для вашей компании Тактически, будьте уверены что вы имеете краткий еженедельный отчет, включающий количество сотрудников, поток наличности, прогноз как на ближайшие месяцы, так и на то, когда закончатся деньги. Развитие бизнеса/Продажи: не делайте этого до тех пор, пока продукт не будет готов к началу работы с партнерами. Готовность означает, что продукт находится в состоянии, при котором вы можете оперативно изменить продуктовые линейки. Старая пословица гласит: «Ваши партнеры могут любить вас до смерти». Так что выбирайте свои сражения грамотно, и будьте модульными настолько, насколько можете. Учтите что 80% сделок по развитию бизнеса не достигают того уровня возврата, которого вы от них ожидаете. В танго участвуют двое, и каждый раз, когда вы боретесь со слоном, это никак не отражается на вашем счете. Если у вас компания с меняющимися возможностями партнерства, прекрасно — но предвидьте изменения в условиях сделки, особенно если вы так рано заключаете сделку со слоном, испытывающим вас. С другой стороны — правильный продукт, правильные партнеры и правильная сделка в правильное время могут привести вас в землю обетованную. Операционная деятельность: арендуйте, а не покупайте. Не пытайтесь в неё даже влазить, если это возможно. Поддерживайте расходы минимальными, а компанию — максимально экономной. Ищите наиболее благоприятные сделки и условия для начала деятельности из всех возможных, но не заключайте длительные соглашения. То, что сейчас выглядит хорошей скидкой, может не быть таковой в будущем. И вы не можете знать объемы чего-либо до тех пор, пока не начнете работать. Команда: создавайте по потребностям, а не для вида. Слишком часто инвесторы, партнеры, пресса и прочие имеют поверхностное восприятие команды. Громкие имена + известные логотипы = много головной боли. Инвестирование: используйте правило «6-ти месяцев». Если вы ищете финансирование шесть месяцев подряд и встречались с половиной Sand Hill Road, остановитесь, бросьте и бегите. Сложите эту палатку и разверните новую. Существует «период полураспада», по истечении которого вы рискуете оказаться ни с чем. Чем дольше вы ищите инвестирование, тем более «несвежим» вы его получаете. В добавок, на самом деле вы не хотите денег от фирм, которые находятся в самом низу вашего списка. Такова особая психология каждой инвестиционной сделки. Больше расскажу в следующий раз.

Статья взята с хабра, переведена толпой (translate.by)

Говорят, что 70% проблем решаются сами собой. Я, как человек отвественный к этому отношусь скептически.

Но факты вещь упрямая =)

Буквально за 3 дня на работе 2 из 5 проблем над которыми я работал решились сами-собой. Т.е. решились они по причинам не зависящих от меня напрямую.

Начинаю верить =)

Есть один баг, который выдает ошибку такого рода:

Transaction (Process ID 51) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Так вот, нашел интересную статью на RSDN`е.

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

Поехали.

Статья называется

Deadlocks Что такое взаимоблокировки и как с ними бороться

«Блокировка», в отличие от «взаимоблокировки», явление совершенно обычное, и означает лишь то, что транзакция получит некий ресурс в свое распоряжение не сразу, а чуть-чуть подождав, пока другая транзакция не снимет с этого ресурса блокировку, наложенную ранее.

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

Типы блокировок

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

Read Lock – блокировка чтения, она же «коллективная», она же «разделяемая». Смысл этой блокировки в том, что она совместима с точно такими же блокировками. Иными словами, на один и тот же ресурс может быть наложено сколь угодно много коллективных блокировок. В терминологии MSSQL эта блокировка называется Shared Lock, или сокращенно S.

Write Lock – блокировка записи, она же «монопольная», она же «эксклюзивная». Эта блокировка не совместима ни с Read Lock, ни сама с собой, ни с каким либо другим типом блокировок. То есть в один момент времени на один объект может быть наложена только одна монопольная блокировка. Эта блокировка в терминологии MSSQL называется Exclusive Lock, или же сокращенно X.

Update Lock – это промежуточная блокировка, блокировка «обновления». Она совместима с Read Lock, но не совместима с Write Lock и сама с собой. Иными словами на один объект могут быть одновременно наложены одна блокировка обновления, ни одной монопольной блокировки и сколь угодно много коллективных блокировок. Этот тип блокировок введен как раз для снижения риска возникновения взаимоблокировки. Каким именно образом, будет объяснено ниже.

Взаимоблокировка

Большинство способов обеспечения параллелизма, хотя бы отчасти основанных на блокировках, подвержено взаимоблокировкам (deadlock). И хотя известны достаточно остроумные алгоритмы, позволяющие не допускать подобных ситуаций в принципе, в коммерческих приложениях они почти не встречаются. Microsoft SQL Server здесь не является исключением, и также подвержен взаимоблокировкам (они же «мертвые блокировки» или «тупиковые ситуации»).

Взаимоблокировка, как можно понять из названия – это ситуация, когда транзакции блокируют друг друга таким образом, что дальнейшее выполнение невозможно. В силу протокола двухфазной блокировки ни одна из участвующих во взаимоблокировке транзакций не может отпустить уже захваченные ей ресурсы до того, как наложит блокировки на все, что ей необходимо. А получить все необходимые ресурсы мешают уже наложенные блокировки. Таким образом, получается замкнутый круг. Естественно, и транзакций, и объектов в общем случае может быть сколь угодно много. Разорвать такую блокировку без внешнего вмешательства невозможно, и если не предпринимать специальных усилий, то транзакции будут находиться в состоянии ожидания бесконечно долго. Разрешить подобную ситуацию можно лишь путем отмены хотя бы одной из транзакций.

imestamp based

Существуют механизмы, позволяющие вообще не допускать тупиковых ситуаций при использовании протокола двухфазной блокировки, например, на основе временных меток (timestamp).

ПРИМЕЧАНИЕ

Здесь главное – не запутаться. Существует как способ обеспечения параллелизма на основе временных меток – это одна из альтернатив протоколу двухфазной блокировки, так и способ предотвращения тупиковых ситуаций. Это два совершенно разных механизма, и сейчас мы обсуждаем именно способ предотвращения взаимоблокировок.

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

1. «ожидание-гибель» (wait-die). Если транзакция T1 «старше» Т2, тогда транзакции Т1 разрешается пребывать в состоянии ожидания на блокировке. Если же Т1 «младше» T2, тогда Т1 откатывается.
2. «ранение-ожидание» (wound-wait). Если транзакция T1 «старше» T2, тогда T1 «ранит» T2; ранение обычно носит «смертельный» характер – транзакция Т2 откатывается, если только к моменту получения «ранения» T2 не оказывается уже завершенной. В этом случае Т2 «выживает» и отката не происходит. Если же Т1 «младше» Т2, тогда Т1 разрешается находиться в состоянии ожидания на блокировке.
3. Timeout based

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

   Wait-for graph based

   Существуют и более удачный способ определения взаимоблокировок (хотя и более трудоемкий). Для этого менеджер блокировок строит направленный граф, который называется «графом ожидания» (wait-for graph). В вершинах этого графа находятся транзакции, а в ребрах – зависимости. Например, ребро Ti->Tj появляется в том случае, если Ti ждет, пока Tj освободит какой-нибудь объект. Таким образом, если в графе ожидания возникает цикл (T1->T2->…->Tn->T1), то T1 ждет сама себя, как и все остальные n транзакций в цикле, следовательно, транзакции заблокированы намертво. В данном случае обнаружение взаимоблокировок сводится к нахождению замкнутых циклов в графе ожидания. Сами зависимости в граф добавляются и уничтожаются по мере получения и снятия блокировок, технически в этом ничего сложного нет. Сложность лишь в том, как часто менеджер блокировок должен проверять граф ожидания на наличие циклов. Теоретически это можно делать каждый раз при добавлении новой зависимости, однако делать проверки так часто слишком накладно, поскольку, как правило, количество обычных блокировок намного выше мертвых, к тому же сама взаимоблокировка никуда не денется и дождется, пока за ней придут. Поэтому проверять наличие циклов можно либо когда в граф добавляется какое-то фиксированное количество граней, либо опять же, по истечении некоего таймаута. Но здесь, в отличие от предыдущего способа, гарантируется, что будет найдена именно мертвая блокировка, а также, что мы обнаружим все мертвые блокировки, а не только те, которые продержались достаточно долго.

   Вдобавок здесь сервер обладает куда большей информацией о тупиковой ситуации, что позволяет ему с меньшими потерями разрешить конфликт. Разорвать взаимоблокировку, как уже говорилось, можно лишь отменив одну из транзакций, входящих в замкнутый цикл. Сервер при выборе жертвы может руководствоваться следующими соображениями:

   • Объем работы, проделанный транзакцией (вся эта работа будет утеряна в случае отмены).
   • Количество работы, которое придется проделать, чтобы произвести отмену транзакции. Менеджер должен стараться избегать отмены транзакции, которая практически завершена.
   • Количество циклов, в которых участвует транзакция. Теоретически транзакция может входить в несколько циклов в графе ожидания, таким образом, отмена одной транзакции может привести к снятию нескольких взаимоблокировок.
   • Одна и та же транзакция может несколько раз подряд войти в тупиковую ситуацию и быть отмененной, перезапуститься и опять попасть в цикл. Чтобы избежать подобного циклического рестарта, алгоритм выбора жертвы должен также учитывать, сколько раз транзакция была отменена из-за мертвых блокировок.

Timeout based

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

Wait-for graph based

Существуют и более удачный способ определения взаимоблокировок (хотя и более трудоемкий). Для этого менеджер блокировок строит направленный граф, который называется «графом ожидания» (wait-for graph). В вершинах этого графа находятся транзакции, а в ребрах – зависимости. Например, ребро Ti->Tj появляется в том случае, если Ti ждет, пока Tj освободит какой-нибудь объект. Таким образом, если в графе ожидания возникает цикл (T1->T2->…->Tn->T1), то T1 ждет сама себя, как и все остальные n транзакций в цикле, следовательно, транзакции заблокированы намертво. В данном случае обнаружение взаимоблокировок сводится к нахождению замкнутых циклов в графе ожидания. Сами зависимости в граф добавляются и уничтожаются по мере получения и снятия блокировок, технически в этом ничего сложного нет. Сложность лишь в том, как часто менеджер блокировок должен проверять граф ожидания на наличие циклов. Теоретически это можно делать каждый раз при добавлении новой зависимости, однако делать проверки так часто слишком накладно, поскольку, как правило, количество обычных блокировок намного выше мертвых, к тому же сама взаимоблокировка никуда не денется и дождется, пока за ней придут. Поэтому проверять наличие циклов можно либо когда в граф добавляется какое-то фиксированное количество граней, либо опять же, по истечении некоего таймаута. Но здесь, в отличие от предыдущего способа, гарантируется, что будет найдена именно мертвая блокировка, а также, что мы обнаружим все мертвые блокировки, а не только те, которые продержались достаточно долго.

Вдобавок здесь сервер обладает куда большей информацией о тупиковой ситуации, что позволяет ему с меньшими потерями разрешить конфликт. Разорвать взаимоблокировку, как уже говорилось, можно лишь отменив одну из транзакций, входящих в замкнутый цикл. Сервер при выборе жертвы может руководствоваться следующими соображениями:

• Объем работы, проделанный транзакцией (вся эта работа будет утеряна в случае отмены).
• Количество работы, которое придется проделать, чтобы произвести отмену транзакции. Менеджер должен стараться избегать отмены транзакции, которая практически завершена.
• Количество циклов, в которых участвует транзакция. Теоретически транзакция может входить в несколько циклов в графе ожидания, таким образом, отмена одной транзакции может привести к снятию нескольких взаимоблокировок.
• Одна и та же транзакция может несколько раз подряд войти в тупиковую ситуацию и быть отмененной, перезапуститься и опять попасть в цикл. Чтобы избежать подобного циклического рестарта, алгоритм выбора жертвы должен также учитывать, сколько раз транзакция была отменена из-за мертвых блокировок.

Сегодня начал проводить эксперименты  с WebParts у себя на сайте.

Много отличных функций добавляются буквально 3-мя щелчками мышки. Уже реализовал webpart для панели входа и для SiteMap.

Вступление. Каникулы после сесии, дома, свободно еще 6 дней...

а мне захотелось написать о концентрации.

Из википедии:

Концентрация внимания — удержание внимания на каком-либо объекте. Такое удержание означает выделение «объекта», в качестве некоторой определенности, фигуры, из общего фона.

Концентрация внимания может быть произвольной, непроизвольной, послепроизвольной

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

Здесь я хочу написать о концентрации в более глобальном понимании - концентрации в работе, бизнесе, если хотите в жизни.

Пример. Вы начинающий веб-мастер, на форумах, в обьявлениях и резюме, везде где только можно вы пишите - я знаю HTML, Java-Script, CSS, Flash, я вам сделаю сайт на этом всем за 75$ ** (все хотят знать все отлично, но нужно получить сперва пару отказов в связи с некомпетентностью, что бы понять что ты знаешь на самом деле и как ты это знаешь). Получив более-менее сложный проект newbie просто захлебнется ( и рано или поздно если он хочет зарабатывать таким образом он придет к тому, что нужно уметь  делать хорошо что-то одно, а потом уже можно знать некие смежные языки, технологии немножко.

Мы с вами понимаем, что человек который знает 1 язык программирования  сделает работу быстрее и лучше чем другой - который знает 3 языка. Это касается и поиска работы.

Концентрация же в бизнесе дает преимущество сразу, особенно если ее уровень выше среднего :)  Ведь вы знаете свою среду лучше конкурентов.

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

Вот так наскоком больше написать не получается (.

Жду коментов.

 

 

** В экономике, когда предприятие занимается бизнесом сразу в нескольких галузях, причем они смежны и в каждой предприятие "помогает" себе в другой называется синергией.

Пример. Компания которая занимается производством строительных материалов и строительством может сове сырье (готовую продукцию из пр-ва материалов) использовать в строительстве - как следсвие

1) есть клиенты дл сырья,

2) экономия при покупке вышеупомянутого для строительства 

3) Рост прибыли вцелом.

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

Итак, мои советы:

1. Определите, в какое время ваша продуктивность работы максимальна. Как правило это утром. Например, у меня самый продуктивный отрезок времени - с  7  до 10 часов утра. Вставайте пораньше - и делайте самую черную работу, что есть на данный день. Вы и глазом не успеете моргнуть, как переделаете все, что до этого казалось не подъемным.
2. Старайтесь не брать работу “на вчера”. Это сбивает весь ритм жизни и принуждает жить в режиме спешки. Как следствие - спланировать свое время практически не возможно.
3. Работайте ритмично. Определите время отдыха и время работы. Если работы нет (и такое бывает) - отдыхайте, не сидите за компьютером в перечитывании баша или еще чего-то. Это убивает ваше время, совсем не расслабляя глаза. Глаза должны отдыхать.
4. Не набирайте работы больше, чем можете “проглотить”. В погоне за многими задачами можно не выполнить до конца ни одной и сорвать сроки.
5. Записывайте себе задачи (можно в уме, но лучше на бумаге - зрительная память - очень сильное оружие) на следующий день (можно даже на пару дней вперед). Если удобно делать на бумаге - делайте это на бумаге. Также можно воспользоваться такими программами, как Toggl или SlimTimer (обе на английском языке).
6. Делайте самые сложные задачи в первую очередь, не откладывая их на потом. Сделав пару сложных задач можно поощрить себя, например прогулкой с любимой девушкой.
7. Пару часов в день уделяйте самообучению. Фрилансер, который не обучается новому - варится в своем соку и может отстать в знании технологий уже через полгода-год от других фрилансеров, да и от требований на рынке.
8. Если клиентов стает очень много - повышайте цены. Не стоит тратить больше времени на работу в погонях за большими деньгами. И не стоит боятся, что клиенты разбегутся. Да, часть из них уйдет, но те, что останутся за счет увеличенных цен будут давать как минимум те же прибыли, а вот работать Вы будете меньше. Главное правда с повышением цен не перебарщивайте.
9. “Переключайтесь”. Сидеть и тупо смотреть на экран монитора, когда “не идет” - потеря времени. Займитесь чем-то радикально другим - можно даже пресс покачать или посуду помыть. После такого “отгула” наступает самое настоящее “просветление”.

Я тоже читаю этот блог время-от-времени и вот что сегодня полезного для себя там нашел:

Лично я всегда делаю так. Когда я затеваю очередную идею, то я автоматом в голове прокручиваю наихудший вариант её итога. Когда я знаю наихудший вариант, то я уже не парюсь по этому поводу. Я готов к нему. И я понимаю, что не получится сейчас – сделаю в другой раз

Вообще я считаю, что добиваться цели смысла нет. Нужно её просто выбрать. А выбрав цель идти к ней так, как будто она уже есть. Дело в том, что как правило, когда в итоге добиваешься цели, то понимаешь, что ничего особенного в ней нет. Сначала ты всеми силами рвёшься купить себе дом, а пожив в нём понимаешь, что хочется чего-то ещё, потому что где-то море лазурнее, солнце ярче, женщины красивее, а трава зеленее.

Я «ЗА» то, чтобы в жизни вместо борьбы был фан. А Вы?

 

 

Я немного знаком с психологией, поетому скажу, что это не просто бред или красивые слова, с которыми каждый из нас согласен. В этом есть смысл