Вы знаете, такого рода проекты довольно нишевые, обычно тут требуется не практикуищий врач, а теоретик или профессор, который консультирует группу Data Scientists. Сами врачи тут ни код, ни анализ не пишут.
Когда я еще был в «академии» в Германии, мне и приезд на собеседование (даже два раза!) и переезд компенсировали из гранта. Более того, даже оплатили билет туда-обратно во время переезда, так что я сумел еще на нем приехать обратно через полгода в отпуск… Но не знаю, везде ли так в германии…
Скажите, а перевод этой аббревиатуры как «чипсы» — это какой-то официальный перевод? Мне просто казалось, что тут имеется в виду другое значение этого слова, но я могу ошибаться.
А в чем сила Jigsaw? Я прочитал немного, но там только про модульность. Тот же принцип, что и в .Net Standard, но я не знаю деталей (ни того, ни другого).
А мы, энтерпрайзные .Net-чики, уже годы ждём компилятор Java написанный на Java, и «тогда можно будет говорить о переходе» :)
Да, еще бы и работу с коллекциями сделать более понятной, потому что после LINQ работать что с java.util.collections, что с Guava — это ж просто застрелиться…
Изменилось многое, в частности появился абсолютно новый инструмент — Visual Studio Code.
Это не Visual Studio, это совершенно другое приложение (кстати, кросс-платформенное, так что вполне можете попробовать).
Конечно, фломастеры на вкус все разные, но мне субъективно нравится больше чем Sublime, да и лицензию тут покупать не надо…
Простите за такую задержку с ответом — навалилась работа.
0. Просто Ваш тул я знаю только по habrahabr, больше я нигде его не встречал (а я занимался этой темой в рамках диплома довольно плотно). Но это ладно, многие тулы из области науки не так известны программистам-прагматикам. А вот Resharper знает именно много таких обычных «практиков», и для них это очень хорошая «реперная точка» для оценки Вашего инструмента.
2. Спасибо, я посмотрю. Что касается проверки драйверов, там несколько другая проверка, она основана на спецификации драйверов, а не на особенностях языка. Например если для того, чтобы вызвать Device_Start() вам, согласно спецификации, нужно сначала вызывать Device_Init(), а в Вашем коде есть вероятность, что эта последовательность не будет соблюдена — то это и найдёт анализатор. Если же в Вашем коде вечный цикл или неправильное условие — он это искать не будет — у него таких правил нет.
Поэтому конечно, баги остаются, но драйвера проверяются на то, что они не «сожгут» устройство неправильным вызовом.
3. Там все довольно хитро. Эти все расширяемые системы, которые с одной стороны могут давать определенные заключения и без аннотаций. с другой стороны можно сделать некую глобальную аннотацию (например что запрещено использование алиасов, или что любая структура перед обращением к ней должна быть инициализирована — это всего одна строчка) — и они уже могут найти много чего. Плюс для frama-C есть много плагинов, которые сами создают аннотацию и ловят определенные типы ошибок (алиасы, арифметическое или логическое переполнение и прочее).
Спасибо за Ваши статьи на Хабре — всегда интересно читать!!!
Так получилось, что на двух последних местах работы первым, что я делал, это был перевод большого объема кода с SVN и подобной внутренней системы на TFS. Большинство проблем возникало у людей, кто работал со старой системой 5-10-15 лет и не мог быстро адаптироваться к новой. Я же очень люблю TFS за следующие его возможности:
1) Shelvesets. Мы используем их везде. Не надо больше никаких diff, просто готовишь нужный тебе набор изменений и он доступен любому из твоей команды. Нужно ревью — готовишь Shelveset. Предлагаешь изменения в проект без коммита — делаешь Shelveset. и так далее.
2) Текст коммитов меняется стандартно из окошка истории. Просто открываешь нужный тебе changeset, и можно сделать любое изменение в тексте. Часто бывает полезно, когда закоммитил что-то а не описал в изменении.
3) Баг, если его выбрать и отметить как Resolve, сам закрывается в системе. Очень удобно, не нужно лезть за тикетом. И сам тикет не нужно вписывать…
4) Readonly все, что ты не менял. Всегда знаешь, что уже редактировалось, а что — нет.
5) Alert on change настраивается просто одним кликом в студии. Никаких больше хуков для этого!!!
6) Есть RESTful API для программного создания бага просто одним GET-реквестом (есть и POST), что очень облегчает интеграцию в другие продукты с возможностью быстрого создания бага из твоего приложения.
Есть еще пара мелочей (например быстрое открытие просмотра и сравнения из истории и пр.), но тут дело уже скорее в юзабилити, чем в самой системе как таковой…
Если у меня стоит 3 студии, то чтобы понять какой TFS у меня стоит и работает требуются дополнительные усилия.
Что значит «какой у меня стоит». Локально у вас должно быть несколько workspaces, на сервере можно посмотреть какой репозиторий «промаппен» в какую папку. Я называю workspace так, чтобы было понятно в какой студии он используется в основном — но открывать можно в любой.
После работы с локальным workspace в более старших версиях студии никогда не было проблем с более младшей.
Единственное, для чего это может быть важно — для local workspaces, но их я вообще не использую и если мне нужна локально вся история — я просто использую DCVS с самого начала…
Привык, что никакие файлы проекта не являются «read-only», поэтому (если стоит по крайней мере VS2012) пытаешься включать «local mode».
Ой, а как я привык, что файлы readonly! Сразу понимаешь какие файлы ты менял а какие нет, никуда не надо лезть. Если файл readonly, значит в него ты еще не лазил. Notepad++ при открытии таких файлов не дает их редактировать — сразу все понятно. Правой кнопкой мыши — и TFS => Check-out for edit. Работает даже если файл уже открыт в Notepad++.
Локальные репозитории — это совсем для другого, это попытка добавить DCVS, на мой взгляд тут лучше использовать тогда Git/Hg, потому что они для этого лучше заточены.
Power Tools не может принести новый бранч с сервера на компьютер, для этого все равно придется запустить студию.
PowerTools это такая надстройка над tfs.exe, поэтому он ставится в зависимости от версии VS, у меня стоит несколько версий локально.
Бранчи без проблем достаются тем же tfs.exe, какие хотите и куда хотите.
Довольно часто некие ревизии не надо сливать из версии 1 в версию 2.
А для чего такие ревизии помечать как «смерженные»? Для этого вполне можно сделать частичный мерж и отметить все оставшиеся ревизии лейблами, типа «not to merge in production».
замержить все эти ревизии в одну ревизию версии 2.
А зачем это нужно? При мёрже у вас в истории все-равно будет одна ревизия (на момент коммита мёржа), зато всегда можно посмотреть какие из ревизий в него вошли. Или что Вы пытаетесь достичь этим?
Я привык создавать бранчи для любых вещей, которые потребуют какого то времени или проверок на тестовой машине.
Это делается так:
1) Идете в Pending Changes, делаете Shelve Changes при СНЯТОЙ галочке Preserve changes locally. У вас получается откат всех локальных изменений в Shelveset.
2) Дальше тестируете что хотите.
3) При необходимости сохранить делате снова Shelve без сохранения изменений локально.
4) Возвращаетесь к своим изменениям делая Unshelve с сервера.
TortioseSVN имеет простой и понятный поиск (и фильтр) по истории бранча
Тут я полностью согласен. Но я никогда не пользовался этими возможностями SVN, даже на проектах с 70000 коммитов.
Опишите, пожалуйста, поподробнее сценарии где Вы их используете и как.
Вы ищете решение в общеи виде для любых 4х4 матриц? Или все-таки есть какие-то ограничения?
С четыремя переменными вот такой пример решается на ура:
eigenvectors{{a,b,c,d},{a,c,b,d},{b,c,d,a},{b,a,c,d}}
Каким же образом вы получаете информацию о возможных и невозможных путях исполнения, если Вы не стоите модель кода? Наверняка есть какая-то модель, символическое выполнение кода, посмотроение графа вызовов и прочее. Просто вы используете эту информацию для создания сложных и «продвинутых» правил без использования различного рода solvers/automated theorem prover (SAT, SMT etc.), да?
Интересно! У меня еще появились вопросы?
0. Прежде всего — вы в курсе, что Resharper уже имеет анализатор (и средства рефакторинга) для нативного кода в public EAP (early access programm). Я думаю, многим бы было интересно сравнить Ваш тул именно с этим, широко известным и распространённым тулом.
1. Пробовали ли Вы рассматривать Вашу систему как IRS (Information Retrieval System) и применять к ней (особенно в сравнении с другими аналогичными инструментами) такие классические IRS метрики, как recall and precision?
2. Что Вы называете «анализатором из Visual Studio 2013»? Там есть какой-то продвинутый статический анализатор С++ кода? Или вы тестируете Ваш анализатор против compiler warnings?
Намного интереснее было бы увидеть сравнение с майкрософтовскими анализаторами, что используют такие методы для проверки исходного кода как DASH/SMASH/Yogi, в частности стандартный static driver verifier (sdv.exe), которым проверяются все драйвера и который входит в поставку WDK (Windows Drivers Kit).
3. Все-таки посмотрите в сторону VCC/frama-C. Они, конечно, требуют аннотации кода и явного указания спецификации в виде контрактов, но это очень близкая к вам ниша!
Насколько я понимаю, у вас по сути rule-based checker, что-то вроде FxCop/StyleCop для С++?
Или вы строете модель исходного кода?
Почему Вы не сравниваете Ваш инструмент с тем же VCC (который тоже частично использует систему правил, но применяет их уже к трансформированному коду), либо, например, frama-C, отличный инструмент для статического анализа С++ кода.
P.S.: Я этот вопрос задавал еще года два назад, и так не получил никакого ответа… Сейчас еще раз залогинился, чтобы задать его же…
Дело в том, что мне в 90% случаев не нужно запускать ни одну из программ только для того, чтобы «проверить почту» или «загрузить фид».
Я запускаю апп почты тогда, когда я знаю, что там есть непрочитанное сообщение от важного адресата — и я вижу эту информацию сразу как только приходит такое письмо со всей необходимой мне информацией, чтобы решить — стоит мне сразу лезть в почту или нет.
То же касатеся погоды, времени, фейсбука и твиттера, а также xkcd, я каждое из этих приложений открываю только тогда, когда я точно знаю, что увижу там нужную мне информацию…
Я встречал много профессоров-информатиков, которые считают что процедуральное и объектно-ориентированное программирование, будучи преподанным первым, необратимо калечит наше сознание и воздвигает в нашем сознании некие «рамки», за пределы которых нам сложно выйти.
Поэтому во многих ВУЗах сейчас функциональное программирование преподается до процедурального, как более естественное. И судя по тому, что я вижу — действительно это неплохо работает. Это мне после многих лет ООП сложно на гора выдавать алгоритмы с хвостовой рекурсией или pattern matching, а вот первокурсникам еще не знакомым с другими языками — одинаково сложно всё и это даже как бы проще…
Классическая информатика сразу сбивает тебя с ног тем, что требует большого объема «инсайдерских» знаний об устройстве памяти, указателях, переполнении, стеке и прочем. А вот же Хаскеле невозможно даже переполнение численной переменной (integer overflow), да и запись похожа на математическую…
Там вроде написано, что у них уклон в исследования и всё такое.
Ну это у них написано потому что это университет. Просто в Германии программистов учат везде: от ПТУ (Berufsschule), и института (Fachhochschule) до университетов. При этом «технический» в названии ВУЗа означает то, что там упор идёт на технические специальности (в первую очередь математика, которая есть в каждом семесте) и исследования.
В реальности в ПТУ учат информатике примерно так:
1. Прочитайте книжку «С# для начинающих» и напишите консольное приложение.
2. Сделайте оконное приложение с 5-6 кнопками.
3. Сделайте веб-приложение с 5-6 кнопками.
На этом все заканчивается. Структуры данных и алгоритмы (обычно) не рассматриваются вообще.
В университете же подходят с другой стороны, в результате:
1. Успешно сдав экзамен по Compiler Construction я не мог не то что запрограммировать компилятор, я до конца не понимал весь pipeline, зато в деталях знал какие-то абстрактные вещи (сейчас вот и их не помню).
2. Успешно сдав экзамен по Software Engineering, я вообще не знал что такое SOLID. Паттерны были, но вскользь. Зато было навалом разных автоматов, сетей Маркова и Петри и разного рода математики.
То есть мы проходили вроде бы много, но это каждый раз было как-то очень уж далеко «от народа». Программировать в результате могли немногие и большинство выбирало в качестве диплома теоретические кафедры (математика, механика, теория управления или теория систем).
Я не встречал ещё книг, типа «Паттерны проектирования на F#»,
О, есть такая книга!!! F# for Developers
Это единственная (известная мне) книга по функциональному программированию, где автор рассматривает функциональный язык с точки зрения обычного разработчика (та же Real World Functional Programming от Петричека и Скита, например, даже рядом не стояла).
Да, еще бы и работу с коллекциями сделать более понятной, потому что после LINQ работать что с java.util.collections, что с Guava — это ж просто застрелиться…
Это не Visual Studio, это совершенно другое приложение (кстати, кросс-платформенное, так что вполне можете попробовать).
Конечно, фломастеры на вкус все разные, но мне субъективно нравится больше чем Sublime, да и лицензию тут покупать не надо…
А синхронизацию через OneDrive не пробовали? Она тоже должна быть «из коробки».
0. Просто Ваш тул я знаю только по habrahabr, больше я нигде его не встречал (а я занимался этой темой в рамках диплома довольно плотно). Но это ладно, многие тулы из области науки не так известны программистам-прагматикам. А вот Resharper знает именно много таких обычных «практиков», и для них это очень хорошая «реперная точка» для оценки Вашего инструмента.
2. Спасибо, я посмотрю. Что касается проверки драйверов, там несколько другая проверка, она основана на спецификации драйверов, а не на особенностях языка. Например если для того, чтобы вызвать Device_Start() вам, согласно спецификации, нужно сначала вызывать Device_Init(), а в Вашем коде есть вероятность, что эта последовательность не будет соблюдена — то это и найдёт анализатор. Если же в Вашем коде вечный цикл или неправильное условие — он это искать не будет — у него таких правил нет.
Поэтому конечно, баги остаются, но драйвера проверяются на то, что они не «сожгут» устройство неправильным вызовом.
3. Там все довольно хитро. Эти все расширяемые системы, которые с одной стороны могут давать определенные заключения и без аннотаций. с другой стороны можно сделать некую глобальную аннотацию (например что запрещено использование алиасов, или что любая структура перед обращением к ней должна быть инициализирована — это всего одна строчка) — и они уже могут найти много чего. Плюс для frama-C есть много плагинов, которые сами создают аннотацию и ловят определенные типы ошибок (алиасы, арифметическое или логическое переполнение и прочее).
Спасибо за Ваши статьи на Хабре — всегда интересно читать!!!
Поэтому только Java., Python и Matlab форева :)
1) Shelvesets. Мы используем их везде. Не надо больше никаких diff, просто готовишь нужный тебе набор изменений и он доступен любому из твоей команды. Нужно ревью — готовишь Shelveset. Предлагаешь изменения в проект без коммита — делаешь Shelveset. и так далее.
2) Текст коммитов меняется стандартно из окошка истории. Просто открываешь нужный тебе changeset, и можно сделать любое изменение в тексте. Часто бывает полезно, когда закоммитил что-то а не описал в изменении.
3) Баг, если его выбрать и отметить как Resolve, сам закрывается в системе. Очень удобно, не нужно лезть за тикетом. И сам тикет не нужно вписывать…
4) Readonly все, что ты не менял. Всегда знаешь, что уже редактировалось, а что — нет.
5) Alert on change настраивается просто одним кликом в студии. Никаких больше хуков для этого!!!
6) Есть RESTful API для программного создания бага просто одним GET-реквестом (есть и POST), что очень облегчает интеграцию в другие продукты с возможностью быстрого создания бага из твоего приложения.
Есть еще пара мелочей (например быстрое открытие просмотра и сравнения из истории и пр.), но тут дело уже скорее в юзабилити, чем в самой системе как таковой…
Что значит «какой у меня стоит». Локально у вас должно быть несколько workspaces, на сервере можно посмотреть какой репозиторий «промаппен» в какую папку. Я называю workspace так, чтобы было понятно в какой студии он используется в основном — но открывать можно в любой.
После работы с локальным workspace в более старших версиях студии никогда не было проблем с более младшей.
Единственное, для чего это может быть важно — для local workspaces, но их я вообще не использую и если мне нужна локально вся история — я просто использую DCVS с самого начала…
Ой, а как я привык, что файлы readonly! Сразу понимаешь какие файлы ты менял а какие нет, никуда не надо лезть. Если файл readonly, значит в него ты еще не лазил. Notepad++ при открытии таких файлов не дает их редактировать — сразу все понятно. Правой кнопкой мыши — и TFS => Check-out for edit. Работает даже если файл уже открыт в Notepad++.
Локальные репозитории — это совсем для другого, это попытка добавить DCVS, на мой взгляд тут лучше использовать тогда Git/Hg, потому что они для этого лучше заточены.
PowerTools это такая надстройка над tfs.exe, поэтому он ставится в зависимости от версии VS, у меня стоит несколько версий локально.
Бранчи без проблем достаются тем же tfs.exe, какие хотите и куда хотите.
А для чего такие ревизии помечать как «смерженные»? Для этого вполне можно сделать частичный мерж и отметить все оставшиеся ревизии лейблами, типа «not to merge in production».
А зачем это нужно? При мёрже у вас в истории все-равно будет одна ревизия (на момент коммита мёржа), зато всегда можно посмотреть какие из ревизий в него вошли. Или что Вы пытаетесь достичь этим?
Это делается так:
1) Идете в Pending Changes, делаете Shelve Changes при СНЯТОЙ галочке Preserve changes locally. У вас получается откат всех локальных изменений в Shelveset.
2) Дальше тестируете что хотите.
3) При необходимости сохранить делате снова Shelve без сохранения изменений локально.
4) Возвращаетесь к своим изменениям делая Unshelve с сервера.
Если нужно переключать ветки — вот одно из решений через командную строку: stackoverflow.com/questions/10240216/team-foundation-server-switch-between-branches
Тут я полностью согласен. Но я никогда не пользовался этими возможностями SVN, даже на проектах с 70000 коммитов.
Опишите, пожалуйста, поподробнее сценарии где Вы их используете и как.
С четыремя переменными вот такой пример решается на ура:
eigenvectors{{a,b,c,d},{a,c,b,d},{b,c,d,a},{b,a,c,d}}
Каким же образом вы получаете информацию о возможных и невозможных путях исполнения, если Вы не стоите модель кода? Наверняка есть какая-то модель, символическое выполнение кода, посмотроение графа вызовов и прочее. Просто вы используете эту информацию для создания сложных и «продвинутых» правил без использования различного рода solvers/automated theorem prover (SAT, SMT etc.), да?
Интересно! У меня еще появились вопросы?
0. Прежде всего — вы в курсе, что Resharper уже имеет анализатор (и средства рефакторинга) для нативного кода в public EAP (early access programm). Я думаю, многим бы было интересно сравнить Ваш тул именно с этим, широко известным и распространённым тулом.
1. Пробовали ли Вы рассматривать Вашу систему как IRS (Information Retrieval System) и применять к ней (особенно в сравнении с другими аналогичными инструментами) такие классические IRS метрики, как recall and precision?
2. Что Вы называете «анализатором из Visual Studio 2013»? Там есть какой-то продвинутый статический анализатор С++ кода? Или вы тестируете Ваш анализатор против compiler warnings?
Намного интереснее было бы увидеть сравнение с майкрософтовскими анализаторами, что используют такие методы для проверки исходного кода как DASH/SMASH/Yogi, в частности стандартный static driver verifier (sdv.exe), которым проверяются все драйвера и который входит в поставку WDK (Windows Drivers Kit).
3. Все-таки посмотрите в сторону VCC/frama-C. Они, конечно, требуют аннотации кода и явного указания спецификации в виде контрактов, но это очень близкая к вам ниша!
Или вы строете модель исходного кода?
Почему Вы не сравниваете Ваш инструмент с тем же VCC (который тоже частично использует систему правил, но применяет их уже к трансформированному коду), либо, например, frama-C, отличный инструмент для статического анализа С++ кода.
P.S.: Я этот вопрос задавал еще года два назад, и так не получил никакого ответа… Сейчас еще раз залогинился, чтобы задать его же…
Я запускаю апп почты тогда, когда я знаю, что там есть непрочитанное сообщение от важного адресата — и я вижу эту информацию сразу как только приходит такое письмо со всей необходимой мне информацией, чтобы решить — стоит мне сразу лезть в почту или нет.
То же касатеся погоды, времени, фейсбука и твиттера, а также xkcd, я каждое из этих приложений открываю только тогда, когда я точно знаю, что увижу там нужную мне информацию…
Поэтому во многих ВУЗах сейчас функциональное программирование преподается до процедурального, как более естественное. И судя по тому, что я вижу — действительно это неплохо работает. Это мне после многих лет ООП сложно на гора выдавать алгоритмы с хвостовой рекурсией или pattern matching, а вот первокурсникам еще не знакомым с другими языками — одинаково сложно всё и это даже как бы проще…
Классическая информатика сразу сбивает тебя с ног тем, что требует большого объема «инсайдерских» знаний об устройстве памяти, указателях, переполнении, стеке и прочем. А вот же Хаскеле невозможно даже переполнение численной переменной (integer overflow), да и запись похожа на математическую…
Ну это у них написано потому что это университет. Просто в Германии программистов учат везде: от ПТУ (Berufsschule), и института (Fachhochschule) до университетов. При этом «технический» в названии ВУЗа означает то, что там упор идёт на технические специальности (в первую очередь математика, которая есть в каждом семесте) и исследования.
В реальности в ПТУ учат информатике примерно так:
1. Прочитайте книжку «С# для начинающих» и напишите консольное приложение.
2. Сделайте оконное приложение с 5-6 кнопками.
3. Сделайте веб-приложение с 5-6 кнопками.
На этом все заканчивается. Структуры данных и алгоритмы (обычно) не рассматриваются вообще.
В университете же подходят с другой стороны, в результате:
1. Успешно сдав экзамен по Compiler Construction я не мог не то что запрограммировать компилятор, я до конца не понимал весь pipeline, зато в деталях знал какие-то абстрактные вещи (сейчас вот и их не помню).
2. Успешно сдав экзамен по Software Engineering, я вообще не знал что такое SOLID. Паттерны были, но вскользь. Зато было навалом разных автоматов, сетей Маркова и Петри и разного рода математики.
То есть мы проходили вроде бы много, но это каждый раз было как-то очень уж далеко «от народа». Программировать в результате могли немногие и большинство выбирало в качестве диплома теоретические кафедры (математика, механика, теория управления или теория систем).
О, есть такая книга!!!
F# for Developers
Это единственная (известная мне) книга по функциональному программированию, где автор рассматривает функциональный язык с точки зрения обычного разработчика (та же Real World Functional Programming от Петричека и Скита, например, даже рядом не стояла).