«Битрикс24» встречается в тексте 24 раза, про иконку «24» промолчу… Может пересмотрите стратегию и сделаете акцент на полезность контента, а не на SEO?
Или хотя бы заголовок смените на рекламный, чтобы диссонанса не было.
Кстати, у уведомлений по электронной почте в Redmine есть еще один фатальный недостаток. Redmine не отдает страничку с задачей пока не отправит письмо на сервер и, если с почтовым сервером происходит что-то плохое, то страничка с задачей не отдается пользователю достаточно долго (до 15 секунд).
У нас настроена асинхронная отправка почты — такой проблемы нет.
P.S. C этой настройкой были проблемы в старых версиях Redmine (пару лет назад).
Даже для таких программистов можно попробовать объяснить простые правила, я попробовал :)
Кстати, не сочтите за рекламу, однако коллеги говорили что про план выполнения я тоже достаточно понятно написал (разумеется, разобраны не все детали, иначе была бы книга).
Сомнительно выглядит выделенный текст — последовательно увеличивающиеся значения полезны тем, что не приводят к расщеплению страниц, как они влияют на эффективность некластерных индексов непонятно.
Не написано только, что кластерный ключ вовсе не обязан быть первичным ключом таблицы
Написано, см. главу Обязательно ли создавать кластеризованный индекс на столбце с первичным ключом?
Disclaimer: да, я понимаю что это перевод, к переводчику претензий нет :)
По содержанию — совсем для начинающих имеет смысл либо более сфокусированное изложение на отдельных деталях (чтобы было понимание «почему», а не «освой индексы за 21 минуту»), либо тезисы с отсылкой на отдельные статьи.
Для людей с опытом недостаточно качественно (лучше sqlskills почитать), см. пример ниже.
In some cases, a surrogate primary key can be an even better choice because, in addition to being unique, the values are small and added sequentially, making the nonclustered indexes that reference those values more efficient as well.
В некоторых случаях лучшим выбором будет суррогатный первичный ключ, обладающий не только признаком уникальности, но и малым размеров, а значения которого увеличиваются последовательно, что делает некластеризованные индексы, основанные на этом значении более эффективными.
Сомнительно выглядит выделенный текст — последовательно увеличивающиеся значения полезны тем, что не приводят к расщеплению страниц, как они влияют на эффективность некластерных индексов непонятно.
Допускаю, что я могу чего-то не знать, однако, в этом случае подобное точно стоило бы объяснить.
P.S. Есть ещё спорные моменты, однако не хочется начинать холивар :)
Что-то вроде этого?
По мне, с учётом того, что релизиться чаще чем раз в день вещь странная, можно просто настроить TeamCity у себя дома (если нет возможности сделать это на сервере), для публикации после билда. Если TeamCity слишком тяжеловесно — скрипт написать.
Читаю:
>cоучредитель сервиса Freckle Time Tracking, которому 1 декабря исполнилось 5 лет, делится 5 самыми значимыми вещами, которые он узнал за это время
Первая мысль — как он смог стать соучредителем сервиса в 5 лет? о_О :)
Зависимость от инструментов может не нравиться.
Однако, могу предложить аналогию: ходить нужно всегда пешком, потому что автомобили и самолёты — это для слабаков, зависимых от технического прогресса и не контролирующих весь процесс целиком :)
От задачи, опять же, многое зависит. Если, например, писать оптимизатор SQL-запросов — скорость набора отходит не на второй, а на какой-то запредельный план и если есть другие средства проверки корректности кода — то можно хоть в блокноте писать. Хотя, конечно, лучше в sublime/vim/notepad++ :)
Автор исходного поста по крайней мере честен — признаётся что любит потроллить :)
По поводу неудобства TDD в Visual Studio — как раз с ReSharper это происходит очень даже удобно.
Сводить Visual Studio + ReSharper к скорости печатания — тоже тот ещё троллинг — помимо повышения скорости эта связка даёт ещё и быструю проверку ошибок, стиля кодирования, предупреждения о возможных проблемах, не говоря уже про рефакторинг.
Про скорость печатания… Может конечно всё очень индивидуально, но лично у меня программирование идёт двумя способами, которые иногда пересекаются:
1) Подумать как сделать, быстро написать, причесать.
2) Подумать как сделать, понять что лучше разбить задачу на мелкие, вероятно описать архитектуру, мелкие задачи решить способами 1 и/или 2. После этого интегрировать в общее решение, выполнить тесты, сделать ревью, вероятно рефакторинг.
И для таких вариантов VS + ReSharper тоже весьма полезны.
P.S. Всё это не относится к математическим/алгоритмическим задачам, где собственно программирование занимает очень небольшой процент времени.
Что касается библиотек на .NET от Джона Скита, ещё вполне интересны protobuf-csharp-port и unconstrained-melody.
Первая понятно о чём (кстати, есть более активно развивающаяся альтернатива — protobuf-net), а вторая позволяет задавать нетипичные ограничения для generics.
Правда сложилось так, что ни одним из них сам не пользовался, но имею в виду, если попадётся подходящая задача.
Хочу дать несколько советов автору из личного опыта:
1) Пользуйтесь DBCC DROPCLEANBUFFERS и DBCC FREEPROCCACHE (в данном случае менее критично). Без этого можно получить недостоверные результаты. Про измерение секунд выше уже говорили.
2) Анализируйте планы выполнения запросов — это даст дополнительную пищу для размышлений. Например, вероятно интересным наблюдением будет то, что индекс не очень помогает при поиске по шаблону "%x%" — разве что может использоваться чтобы сканировать не таблицу а индекс (что иногда на некоторых запросах быстрее, но см. пункт (1)).
P.S. «Индексы лучше работают с таблицами, содержащими большое количество строк» — не очень понятное для меня утверждение. В моём понимании — на маленьком количестве строк сканирование таблицы может быть достаточно эффективным, а индексы работают практически одинаково.
IMHO, у автора получилось вполне неплохое решение для приведённой задачи. Да и конструкция вполне читабельная.
На моих проектах такое не требуется, но если в будущем нужно будет делать такие операции (например в случае legacy database) — подумаю про его использование.
PredicateBuilder пробовали?
Насколько я помню, помимо Or и And (которые, вероятно, будут не самым удобным вариантом) там можно описывать свои предикаты.
Или хотя бы заголовок смените на рекламный, чтобы диссонанса не было.
У нас настроена асинхронная отправка почты — такой проблемы нет.
P.S. C этой настройкой были проблемы в старых версиях Redmine (пару лет назад).
Кстати, не сочтите за рекламу, однако коллеги говорили что про план выполнения я тоже достаточно понятно написал (разумеется, разобраны не все детали, иначе была бы книга).
Про проблемы с GUID хорошо здесь написано.
P.S. Если нужна репликация, лучше хотя бы NEWSEQUENTIALID() использовать.
У меня претензия к этому (из моего комментария):
Написано, см. главу Обязательно ли создавать кластеризованный индекс на столбце с первичным ключом?
P.S. Да, я тоже иногда читаю «по диагонали» :)
По содержанию — совсем для начинающих имеет смысл либо более сфокусированное изложение на отдельных деталях (чтобы было понимание «почему», а не «освой индексы за 21 минуту»), либо тезисы с отсылкой на отдельные статьи.
Для людей с опытом недостаточно качественно (лучше sqlskills почитать), см. пример ниже.
Сомнительно выглядит выделенный текст — последовательно увеличивающиеся значения полезны тем, что не приводят к расщеплению страниц, как они влияют на эффективность некластерных индексов непонятно.
Допускаю, что я могу чего-то не знать, однако, в этом случае подобное точно стоило бы объяснить.
P.S. Есть ещё спорные моменты, однако не хочется начинать холивар :)
Здесь и здесь объясняется разница.
P.S. Дополнительно (сам не пробовал):
здесь Material design для Angular, а здесь — поддержка им компонентов Polymer.
SVN уже несколько лет как не хранит служебную информацию во всех подпапках.
Автор оригинала явно был слишком в восторге — иметь в виду — пожалуй, а ориентироваться на тех у кого Chrome 36 BETA было бы странно.
P.S. О_о выглядит аутентичнее :)
По мне, с учётом того, что релизиться чаще чем раз в день вещь странная, можно просто настроить TeamCity у себя дома (если нет возможности сделать это на сервере), для публикации после билда. Если TeamCity слишком тяжеловесно — скрипт написать.
>cоучредитель сервиса Freckle Time Tracking, которому 1 декабря исполнилось 5 лет, делится 5 самыми значимыми вещами, которые он узнал за это время
Первая мысль — как он смог стать соучредителем сервиса в 5 лет? о_О :)
Однако, могу предложить аналогию: ходить нужно всегда пешком, потому что автомобили и самолёты — это для слабаков, зависимых от технического прогресса и не контролирующих весь процесс целиком :)
От задачи, опять же, многое зависит. Если, например, писать оптимизатор SQL-запросов — скорость набора отходит не на второй, а на какой-то запредельный план и если есть другие средства проверки корректности кода — то можно хоть в блокноте писать. Хотя, конечно, лучше в sublime/vim/notepad++ :)
По поводу неудобства TDD в Visual Studio — как раз с ReSharper это происходит очень даже удобно.
Сводить Visual Studio + ReSharper к скорости печатания — тоже тот ещё троллинг — помимо повышения скорости эта связка даёт ещё и быструю проверку ошибок, стиля кодирования, предупреждения о возможных проблемах, не говоря уже про рефакторинг.
Про скорость печатания… Может конечно всё очень индивидуально, но лично у меня программирование идёт двумя способами, которые иногда пересекаются:
1) Подумать как сделать, быстро написать, причесать.
2) Подумать как сделать, понять что лучше разбить задачу на мелкие, вероятно описать архитектуру, мелкие задачи решить способами 1 и/или 2. После этого интегрировать в общее решение, выполнить тесты, сделать ревью, вероятно рефакторинг.
И для таких вариантов VS + ReSharper тоже весьма полезны.
P.S. Всё это не относится к математическим/алгоритмическим задачам, где собственно программирование занимает очень небольшой процент времени.
Пост прошлогодний, глобально же вы мыслите :)
Что касается библиотек на .NET от Джона Скита, ещё вполне интересны protobuf-csharp-port и unconstrained-melody.
Первая понятно о чём (кстати, есть более активно развивающаяся альтернатива — protobuf-net), а вторая позволяет задавать нетипичные ограничения для generics.
Правда сложилось так, что ни одним из них сам не пользовался, но имею в виду, если попадётся подходящая задача.
1) Пользуйтесь DBCC DROPCLEANBUFFERS и DBCC FREEPROCCACHE (в данном случае менее критично). Без этого можно получить недостоверные результаты. Про измерение секунд выше уже говорили.
2) Анализируйте планы выполнения запросов — это даст дополнительную пищу для размышлений. Например, вероятно интересным наблюдением будет то, что индекс не очень помогает при поиске по шаблону "%x%" — разве что может использоваться чтобы сканировать не таблицу а индекс (что иногда на некоторых запросах быстрее, но см. пункт (1)).
P.S. «Индексы лучше работают с таблицами, содержащими большое количество строк» — не очень понятное для меня утверждение. В моём понимании — на маленьком количестве строк сканирование таблицы может быть достаточно эффективным, а индексы работают практически одинаково.
На моих проектах такое не требуется, но если в будущем нужно будет делать такие операции (например в случае legacy database) — подумаю про его использование.
Насколько я помню, помимо Or и And (которые, вероятно, будут не самым удобным вариантом) там можно описывать свои предикаты.