Как раз планировал взглянуть на наиболее интересные из метрошных WPF библиотек на выходных — Elysium и MahApps.Metro.
Спасибо за подсказку. Для «родного» решения на .Net 4.5 — WindowsChrome более правильный подход. Хотя, для нестандартной формы окна совсем без костылей там, похоже, тоже не обойтись. Поищу решения для проблемы с тулбаром, посмотрю на ваш код и обновлю статью.
Спасибо. Я раньше и не знал про такую возможность — очень удобно.
Добавил эту функцию к коду на github'е (надо будет только посмотреть потом как улучшить производительность).
Ваша правда, для липучих заметок стиль идеально подходит, а поменять кнопки или привязаться к клавишам при полном доступе к имплементации — не проблема
Для сравнения — вот окно 2012 студии без открытых проектов. Поначалу непривычно, но после нескольких месяцев становится более-менее естественным и начинает ассоциироваться со средствами разработки в целом, а не только со стикерами.
Ветка в git'е это указатель на commit; в пустой репозитории веток еще нет. «Пустая ветка» это глюк (если у вас репозиторий не упакован, взгляните в файлы в .git/refs/heads — там всегда sha commit'а).
Вы правы, git спокойно может работать без ветки «master». Но вот UI клиенты и библиотеки поверх файловой структуры git'а часто предполагают что refs/heads/master и HEAD определены всегда и взрываются если это не так.
Чтобы не запутаться в построениях, можно обратить внимание, что проeкции положения собак на диагонали квадрата совпадают с проeкцией волка, а потом доказать что а) собаки могут сохранять эту ситуацию за счет 1.5 > sqrt(2), б) когда волк доползeт до границы, его встретят 2, а в углу все 3 собаки.
Картинка #5 задает классификацию: разбиение приращений на группы 1-6.
Задача нейронной сети будет предсказать не точное значение приращения, а только группу.
Картинка #6 иллюстрирует применение этой классификации к входным данным:
6.верх — исходные приращения, 6.низ — классы/группы в которые они попали.
Как некоторое введение в алгоритмическую торговлю статья интересная, но автор, видимо, рассчитывает что все читатели хорошо знают основы нейронных сетей.
Можно просто показывать заметную надпись «статья обновилась» рядом с [refresh] справа, без добавления новых элементов интерфейса. Это будет полезно для любой статьи.
Если автор решит поподкастить — читатели это заметят. Может только добавить иконку на усмотрение автора, что мол «это трансляция, не переключайтесь», но делать разную функциональность для «трансляций» и «не трансляций» необязательно.
По поводу git mv git wiki говорит что это полный аналог удаления файла и добавления с новым именем; хотя то что вы говорите про «если файл изменился не сильно, он поймёт» я уже несколько раз встречал в обсуждениях git'а — надо будет разобраться. Тут только надо понимать, поправьте, если я ошибаюсь, что ядру git'а это без разницы — git может дать полный snapshot в точке #N и в точке #N-1, а что конкретно произошло между этими моментами — это уже проблема интерпретации клиента или дополнительных утилит.
По поводу нескольких проектов в репозитории — согласен, я бы старался избегать. Зачем смешивать отслеживание изменений в нескольких несвязных проектах? Submodules — это все-таки больше «внешние» проекты, тоже не совсем то.
Я говорил про объединение данных репозиторий — кажется, это делается через .git/objects/info/alternates. Это не связано с подпроектами, скорее с оптимизацией крупных хранилищ исходного кода. Например, если вы хотите сделать свой github с поддержкой fork'ов и при этом реально копировать репозитории, то проблемы с местом на жестом диске будут вас преследовать в ночных кошмарах. В случае если папку objects можно расшарить между несколькими репозиториями, такой проблемы не будет. Очевидно, что практический интерес это представляет в основном крупным компаниям с множеством команд и продуктов, ну или хостерам кода типа github, bitbucket, kiln и т.д., но с точки зрения возможностей git'а, все же полезно знать.
Про .git-овые файлы еще много интересного можно рассказать.
Например, что использование SHA для идентификации содержимого файлов и деревьев естественным образом исключает дублирование данных в репозитории. У git'а нет записи изменений как таковых — что произошло в конкретном commit'е определяется исходя из того, что контрольная сумма у файла (или директории) с данным именем поменялась, а если после commit'а появился один или больше файлов с той же sha, что и до коммита, то это копирование или перемещение. Все очень просто, но с таким подходом отследить переименование файла с одновременным изменением содержимого не получится. Если вам важно прослеживать историю изменений, придется переименовывать и изменять файл в разных коммитах. Кстати, если не ошибаюсь, данные нескольких репозиторий можно хранить совместно, что делает git еще более эффективным для больших проектов.
Еще можно написать как ставятся хуки, описать revwalk, сравнить аннотированые и обычные тэги, ну или алгоритмы вычисления истории изменений, diff, blame… Так что не сдерживайте себя ;)
Ссылка на оценку не помешала бы. Просто два основных продукта Спольски (FogBugz и Kiln начатый года 2-3 назад) сидят на дотнете. Про StackExchange я не заикаюсь, это несколько другая компания, но тоже, в основном, .Net. Правда, последний проект (Trello.com technology stack) на node.js и mongodb, но у Trello толстоватый клиент и в серверной части превалирует задача хранения данных c минимумом логики, так что это скорее из разряда выбора наиболее подходящей технологии под задачу.
Отсутсвие времени жизни батареи без нагрузки напрягает, да и тяжеловато воспринимать производительность без привязки к конкретной задаче. Задачу «конкретно посадить батарею» я конкретной не считаю, хотя судя по результатам, Chrome с этим справился лучше всех. (j/k)
Примером конкретной задачи может быть «Зайти на Хабр и обновлять страницу каждые 2 минуты».
А по этому абстрактному тесту, если, например, одна страница требует 1000 единиц производительности, то получается что с одного заряда батареи браузеры могут показать:
Пока оплачивал интернет, почесал яйца и забронировал два билета на Тайвань.
А если серьезно, то технологии распознавания мимики вовсю развиваются. Осталось только встроить камеру в очки, натренировать софт делать это с близкого расстояния чтобы не выносить камеру на четверть метра вперед и можно базовые команды конфигурить на гримассы. Можно, впрочем, и на акселерометр команды повесить.
Помотал головой или сморщил нос — [cancel]
Кивнул или улыбнулся — [ОК]
Нахмурил брови — [F1]
Закатил глаза — отключить эту осто… чертевшую виртуальную реальность на 15 минут.
Если Вы рассматривали несколько систем контроля версий, можете сказать что подтолкнуло выбрать Mercurial?
Не флейма ради, а с практической точки зрения. Я работаю над проектом с поддержкой Mercurial и с перспективой добавления поддержки Git'а — интересно какие возможности того и другого ценятся в разных ситуациях.
Причины по которым остаются на до-DVCS'ах есть, но они скорее психологические.
Года 3 назад я тоже вытаскивал нашу команду (тоже в «прошлой фирме») с CVS на что-нибудь более современное. Посмотрел на Mercurial, не проникся: он был не очень популярен, хоть и обгонял Git по «дружественности» под Windows (тогда про Git Extensions еще не знали). HG оставил ощущение какой-то «чужеродности» — было ясно что принцип работы несколько другой, но описания делались или программистами в стиле «changeset, head, tag — тут все просто, нечего объяснять!» или маркетологами «мы все возбуждены, это революция!». Тогда остановился на SVN, поскольку мог сделать вводную презентацию, демо проект, помочь с перенастройкой CI сервера и т.д.
Сейчас — да, после нескольких месяцев активной работы на Mercurial и мелких проектов с Git'ом, я понимаю, что назад уже не вернусь. Но тогда, без этого опыта, я просто не смог бы нормально рассказать про удобства организации работы с DVCS.
Где-то полгода назад искал решения для экспорта-импорта файлов Excel на сервере.
Наткнулся на EPPlus и просто пищал от радости: не требует установки Офиса, простой API, не попалось ни единого бага (ну, на наших задачах — несколько worksheet'ов, несложное форматирование).
Проект пятилетний, много серверных модулей и клиентских приложений. К тому времени мы реально использовали в разных местах Interop, OLEDB, CSV и генерацию на основе XML-templates. У всех решений свои проблемы. Мы смотрели в сторону VSTO или Add-in Express'а, но EP+ очень удачно попался под руку.
Производительность EP+ заявляют сравнимую с тем что у вас получается — «Can now load 50 000 cells in seconds».
Да, конкретно у OLEDB — помимо естественных ограничений представления данных как реляционных и установки офисных DLL-ек (чего нам хотелось избежать на сервере), была еще заморочка с автоматическим распознованием типа данных по первым N (default 8) строкам. Если в первых строках в колонке шли цифры, то появление потом цифро-буквенного значения передавалось как DBNull и надо бвло лезть в реестр чтобы это исправить.
Evernote Clearly довольно неплохо с этим справляется (сам evernote ему не нужен). Он как раз заточен под чтение: оставлает на странице только статью, скрывая все остальное. При печати, правда, оставляет слишком большое правое поле.
Но я Вас полностью понимаю — я тоже сначала написал свое расширение, потом нашел почти такое же на github'е.
Спасибо за подсказку. Для «родного» решения на .Net 4.5 — WindowsChrome более правильный подход. Хотя, для нестандартной формы окна совсем без костылей там, похоже, тоже не обойтись. Поищу решения для проблемы с тулбаром, посмотрю на ваш код и обновлю статью.
Добавил эту функцию к коду на github'е (надо будет только посмотреть потом как улучшить производительность).
Для сравнения — вот окно 2012 студии без открытых проектов. Поначалу непривычно, но после нескольких месяцев становится более-менее естественным и начинает ассоциироваться со средствами разработки в целом, а не только со стикерами.
Вы правы, git спокойно может работать без ветки «master». Но вот UI клиенты и библиотеки поверх файловой структуры git'а часто предполагают что refs/heads/master и HEAD определены всегда и взрываются если это не так.
Но сама идея с тем чтобы кататься туда-сюда должна быть правильной, только линейное увеличение колебаний явно будет недостаточно.
Чтобы не запутаться в построениях, можно обратить внимание, что проeкции положения собак на диагонали квадрата совпадают с проeкцией волка, а потом доказать что а) собаки могут сохранять эту ситуацию за счет 1.5 > sqrt(2), б) когда волк доползeт до границы, его встретят 2, а в углу все 3 собаки.
Задача нейронной сети будет предсказать не точное значение приращения, а только группу.
Картинка #6 иллюстрирует применение этой классификации к входным данным:
6.верх — исходные приращения, 6.низ — классы/группы в которые они попали.
Как некоторое введение в алгоритмическую торговлю статья интересная, но автор, видимо, рассчитывает что все читатели хорошо знают основы нейронных сетей.
Если автор решит поподкастить — читатели это заметят. Может только добавить иконку на усмотрение автора, что мол «это трансляция, не переключайтесь», но делать разную функциональность для «трансляций» и «не трансляций» необязательно.
По поводу нескольких проектов в репозитории — согласен, я бы старался избегать. Зачем смешивать отслеживание изменений в нескольких несвязных проектах? Submodules — это все-таки больше «внешние» проекты, тоже не совсем то.
Я говорил про объединение данных репозиторий — кажется, это делается через .git/objects/info/alternates. Это не связано с подпроектами, скорее с оптимизацией крупных хранилищ исходного кода. Например, если вы хотите сделать свой github с поддержкой fork'ов и при этом реально копировать репозитории, то проблемы с местом на жестом диске будут вас преследовать в ночных кошмарах. В случае если папку objects можно расшарить между несколькими репозиториями, такой проблемы не будет. Очевидно, что практический интерес это представляет в основном крупным компаниям с множеством команд и продуктов, ну или хостерам кода типа github, bitbucket, kiln и т.д., но с точки зрения возможностей git'а, все же полезно знать.
Например, что использование SHA для идентификации содержимого файлов и деревьев естественным образом исключает дублирование данных в репозитории. У git'а нет записи изменений как таковых — что произошло в конкретном commit'е определяется исходя из того, что контрольная сумма у файла (или директории) с данным именем поменялась, а если после commit'а появился один или больше файлов с той же sha, что и до коммита, то это копирование или перемещение. Все очень просто, но с таким подходом отследить переименование файла с одновременным изменением содержимого не получится. Если вам важно прослеживать историю изменений, придется переименовывать и изменять файл в разных коммитах. Кстати, если не ошибаюсь, данные нескольких репозиторий можно хранить совместно, что делает git еще более эффективным для больших проектов.
Еще можно написать как ставятся хуки, описать revwalk, сравнить аннотированые и обычные тэги, ну или алгоритмы вычисления истории изменений, diff, blame… Так что не сдерживайте себя ;)
А перевод очень хороший, спасибо автору.
Примером конкретной задачи может быть «Зайти на Хабр и обновлять страницу каждые 2 минуты».
А по этому абстрактному тесту, если, например, одна страница требует 1000 единиц производительности, то получается что с одного заряда батареи браузеры могут показать:
— Chrome: 165 страниц
— Firefox: 89
— IE 10: 92
— IE 9: 87
— Opera: 152
А если серьезно, то технологии распознавания мимики вовсю развиваются. Осталось только встроить камеру в очки, натренировать софт делать это с близкого расстояния чтобы не выносить камеру на четверть метра вперед и можно базовые команды конфигурить на гримассы. Можно, впрочем, и на акселерометр команды повесить.
Помотал головой или сморщил нос — [cancel]
Кивнул или улыбнулся — [ОК]
Нахмурил брови — [F1]
Закатил глаза — отключить эту осто… чертевшую виртуальную реальность на 15 минут.
Не флейма ради, а с практической точки зрения. Я работаю над проектом с поддержкой Mercurial и с перспективой добавления поддержки Git'а — интересно какие возможности того и другого ценятся в разных ситуациях.
>… у всех задача одна и та же – уменьшение сложности системы и, как следствие, жизни программистов.
А вот это — пугает :)
Года 3 назад я тоже вытаскивал нашу команду (тоже в «прошлой фирме») с CVS на что-нибудь более современное. Посмотрел на Mercurial, не проникся: он был не очень популярен, хоть и обгонял Git по «дружественности» под Windows (тогда про Git Extensions еще не знали). HG оставил ощущение какой-то «чужеродности» — было ясно что принцип работы несколько другой, но описания делались или программистами в стиле «changeset, head, tag — тут все просто, нечего объяснять!» или маркетологами «мы все возбуждены, это революция!». Тогда остановился на SVN, поскольку мог сделать вводную презентацию, демо проект, помочь с перенастройкой CI сервера и т.д.
Сейчас — да, после нескольких месяцев активной работы на Mercurial и мелких проектов с Git'ом, я понимаю, что назад уже не вернусь. Но тогда, без этого опыта, я просто не смог бы нормально рассказать про удобства организации работы с DVCS.
Наткнулся на EPPlus и просто пищал от радости: не требует установки Офиса, простой API, не попалось ни единого бага (ну, на наших задачах — несколько worksheet'ов, несложное форматирование).
Проект пятилетний, много серверных модулей и клиентских приложений. К тому времени мы реально использовали в разных местах Interop, OLEDB, CSV и генерацию на основе XML-templates. У всех решений свои проблемы. Мы смотрели в сторону VSTO или Add-in Express'а, но EP+ очень удачно попался под руку.
Производительность EP+ заявляют сравнимую с тем что у вас получается — «Can now load 50 000 cells in seconds».
Да, конкретно у OLEDB — помимо естественных ограничений представления данных как реляционных и установки офисных DLL-ек (чего нам хотелось избежать на сервере), была еще заморочка с автоматическим распознованием типа данных по первым N (default 8) строкам. Если в первых строках в колонке шли цифры, то появление потом цифро-буквенного значения передавалось как DBNull и надо бвло лезть в реестр чтобы это исправить.
Но я Вас полностью понимаю — я тоже сначала написал свое расширение, потом нашел почти такое же на github'е.