— тут я полностью согласен. Я временами увлекаюсь другими сферами деятельности кроме IT и вижу, что, например, полноценное проектирование происходит прежде чем начинаешь что-то ваять, при чем уровень проектирования и документации, как правило, выше чем это можно увидеть в IT. Из чего можно сделать вывод, что айтишники — ленивые люди с отблеском элитарности на своем ЧСВ, которые к работе подходят зачастую небрежно.
Статья огромная. Автора понесло. Много полезного но нет целостности изложения. В любом случае спасибо за вашу работу. Хотелось бы почитать подобную вашу работу, которой вы уделили бы больше времени на доработку мелким надфилем. А еще лучше я хотел бы видеть именно эту статью снятую в формате как тот же ролик про 7 красных линий. Тема достойная
Общество действительно показывает свою болезненность и в большинстве своей массы демонстрирует калейдоскопичность во всех сферах познания, бессвязность знаний. Но что уж поделать. Других у нас нет. На фоне всей безотрадности, все таки, мы видим, что проекты реализуются. Не у всех и не всегда так как хотелось бы, но Интернет полон сайтов, а github полон интересных идей, многие из которых пошли в жизнь. Так что давайте побольше веры в людей и побольше позитивных ноток.
Судя по репозиториям на GitHub разработчики технологии адаптировали HoloToolkit только для Unity3D. Но есть и просто https://github.com/Microsoft/HoloToolkit, видимо для хардкорщиков, которые смогут собрать приложение своими руками
Думаю Unity — просто первая из многих движков, под которые вскоре будут написаны библиотеки HoloToolkit. На это намекают несколько мест, в исходниках HoloToolkit, где упоминается Unreal Engine.
Это всего лишь первая ласточка. Об этом и в статье говорится:
Разрабатывать под HoloLens имеет смысл начинать прямо сейчас потому что уже есть платежеспособный спрос со стороны банков, нефтянки, образования, машиностроения, архитекторов. И у вас есть шанс стать первыми.
Тут вопрос даже не в том — нравится или нет. А в том — на каком языке вся остальная документация по проекту. Вообще важно писать сценарии приемочного тестирования на том же языке, что и вся остальная документация, так как таким образом не происходит расхождения в терминологии. Терминологические войны в проекте — та еще головная боль.
Для BDD это список свойств (фич), который уместно писать вместе с заказчиком.
Уже набило оскомину утверждение, с заказчиком можно/нужно писать сценарии на Gherkin-е. С заказчиком нельзя написать полноценные сценарии тестирования. Заказчик — это такой зверь, которому нужно подавать решение его проблемы в самом вкусном и удобовоспринимаемом виде. Иначе не будет переварено.
Да даже, если речь идет о том, что вы при заказчике пишете сценарии, сами конвертируя в них его требования, то это не будет оценено по достоинству. Заказчику нужна картинка.
Это может быть, например, презентация с набором диаграмм (например user story и job story), но никак не техническая спецификация, коей является Gherkin.
Единственный случай когда с заказчиком можно разрабатывать требования к продукту на Gherkin-е — это когда заказчиком является технарь, либо какой-то отдел вашей же компании (то есть в любом случае технарь).
В других же случаях Gherkin при работе с заказчиком пригодится лишь на этапе утверждения объема работы на разработку. Мол мы вам привели в формально изложенном виде то что будет нами сделано, вы утвердили, мы разрабатываем. И делать это нужно только когда все это было уже изложено в более удобоваримом виде.
В общем, хватит людей в заблуждение вводить. Тут явно должны быть какие то другие формулировки. (Никаких претензий к переводчику, так как в общем статья полезная)
В связке VisualStudio+UnityPlugin+Resharper я смог наладить рабочий процесс, в котором не приходится постоянно следить за хвостами. Думаю, на сегодняшний день это самое оптимальное рабочее окружение для разработки.
Неужели нет инструмента от разработчиков Unity3D, VS или ReSharper, который позволяет при переименовании/перемещении файла скрипта или его перемещении сохранить связи этого скрипта с объектами, которым он назначен? Ведь весь секрет в том, чтобы при переименовании/перемещении скрипта переименовать/переместить соответственно и одноименный *.meta файл, что создается в проекте вместе с самим скриптом. А если такой инструмент есть, то при рефакторинге приложения не должна рушиться его консистентность, а значит и не нужны такие костыли, что описал автор. Откоментируйте меня, если я не прав )
В таком случае можно использовать в дополнение к проверке на null еще и try catch, чтобы исключить такую возможность. Не лежит у меня душа к созданию сущности ( delegate{} ), что не будет задействована в логике выполнения программы )
Это действительно был бы мощный инструмент, если бы давал возможность верстать интерфейс хотя бы как в Андроиде на базовом уровне реализуя компоненты ListView, LinearLayout, FrameLayout, GridView с позиционированием относительно друг друга, а не только относительно родительского элемента. Если этого нет, то все равно приходится писать скрипты для допиливания сложных интерфейсов (Чем многие уже активно и занялись: www.assetstore.unity3d.com/en/#!/content/21430 и т.д.). В таком случае вижу только два улучшения — возможность мирового позиционирования элементов интерфейса (действительно значительное улучшение) и то, что эти элементы являются наследниками GameObject, что убрало лишнюю шизофрению из Unity3D. Все остальное со стороны разрабов пока что просто вода
https://www.youtube.com/watch?v=UgM1FJDxi2o
Статья огромная. Автора понесло. Много полезного но нет целостности изложения. В любом случае спасибо за вашу работу. Хотелось бы почитать подобную вашу работу, которой вы уделили бы больше времени на доработку мелким надфилем. А еще лучше я хотел бы видеть именно эту статью снятую в формате как тот же ролик про 7 красных линий. Тема достойная
Общество действительно показывает свою болезненность и в большинстве своей массы демонстрирует калейдоскопичность во всех сферах познания, бессвязность знаний. Но что уж поделать. Других у нас нет. На фоне всей безотрадности, все таки, мы видим, что проекты реализуются. Не у всех и не всегда так как хотелось бы, но Интернет полон сайтов, а github полон интересных идей, многие из которых пошли в жизнь. Так что давайте побольше веры в людей и побольше позитивных ноток.
Думаю Unity — просто первая из многих движков, под которые вскоре будут написаны библиотеки HoloToolkit. На это намекают несколько мест, в исходниках HoloToolkit, где упоминается Unreal Engine.
Это всего лишь первая ласточка. Об этом и в статье говорится:
Тут вопрос даже не в том — нравится или нет. А в том — на каком языке вся остальная документация по проекту. Вообще важно писать сценарии приемочного тестирования на том же языке, что и вся остальная документация, так как таким образом не происходит расхождения в терминологии. Терминологические войны в проекте — та еще головная боль.
Уже набило оскомину утверждение, с заказчиком можно/нужно писать сценарии на Gherkin-е. С заказчиком нельзя написать полноценные сценарии тестирования. Заказчик — это такой зверь, которому нужно подавать решение его проблемы в самом вкусном и удобовоспринимаемом виде. Иначе не будет переварено.
Да даже, если речь идет о том, что вы при заказчике пишете сценарии, сами конвертируя в них его требования, то это не будет оценено по достоинству. Заказчику нужна картинка.
Это может быть, например, презентация с набором диаграмм (например user story и job story), но никак не техническая спецификация, коей является Gherkin.
Единственный случай когда с заказчиком можно разрабатывать требования к продукту на Gherkin-е — это когда заказчиком является технарь, либо какой-то отдел вашей же компании (то есть в любом случае технарь).
В других же случаях Gherkin при работе с заказчиком пригодится лишь на этапе утверждения объема работы на разработку. Мол мы вам привели в формально изложенном виде то что будет нами сделано, вы утвердили, мы разрабатываем. И делать это нужно только когда все это было уже изложено в более удобоваримом виде.
В общем, хватит людей в заблуждение вводить. Тут явно должны быть какие то другие формулировки. (Никаких претензий к переводчику, так как в общем статья полезная)
www.visualstudio.com/en-us/features/unitytools-vs.aspx
В связке VisualStudio+UnityPlugin+Resharper я смог наладить рабочий процесс, в котором не приходится постоянно следить за хвостами. Думаю, на сегодняшний день это самое оптимальное рабочее окружение для разработки.
Буду рад, если вам это поможет.