В этом году я сделал одну большую вещь - Cisar. Это встроенное в браузер (точнее в F12 DevTools) мини-IDE, предназначенное для создания CSR (Client Side Rendering) кастомизаций в SharePoint. Главная фишка Cisar'а в том, что он поддерживает Live Preview, т.е. набираем код и сразу же, в реальном времени, видим результаты его работы на странице.
Это позволяет работать очень эффективно и создавать решения по кастомизации форм буквально за считанные минуты. Не шучу. Был даже реальный случай: коллега на работе оценил некоторую задачу по кастомизации форм в час работы, там надо было заменить текстовое поле dropdown'ом, причем он (коллега) с CSR очень хорошо дружит. Я с ним поспорил на пиво, что смогу сделать за 3 минуты с помощью Cisar. Проиграл: сделал за 5 :)
Поддерживается CSR для:
Форм списков
Представлений списков
Представлений списков в режиме Quick Edit
НЕ поддерживается на данном этапе CSR для результатов поиска, и вообще Display Templates как класс. Надеюсь это добавить в будущем, но это технически нетривиально.
До последнего времени Cisar плохо работал с не-root сайт-коллекциями, но у меня наконец-то дошли руки это поправить и теперь проблем быть не должно. Но версия все еще Beta, так что огромная просьба, всем кто будет использовать, пишите багрепорты!! Сюда в комментарии, или на GitHub, куда-нибудь в общем... :)
Cisar полностью бесплатен, open source, лицензия "Public Domain" (это означает, делайте вообще все что угодно с ним, никаких ограничений).
С технической точки зрения Cisar - это расширение для Chrome, написанное кстати на TypeScript. Для подсветки синтаксиса используется редактор codemirror. Для отображения списка файлов используется KnockoutJs. Для Live Preview используются результаты нескольких недель копания в кишках CSR, если вы думаете что это просто eval, можете посмотреть код :)
Также, если кто-то вдруг пропустил мои статьи по CSR, с множеством примеров кастомизаций (большинство из которых были созданы с помощью Cisar), ссылки ниже (статьи на английском):
P.S. На самом деле так привык к Cisar, и так удобно, что теперь уже даже пытаюсь его использовать для любого клиентского кода. И как я раньше писал JSOM-код без intellisense!? :)
Прочитал статью Get that job at Google, и очень сильно разочаровался! Ситуация подтвердилась и другими источниками: оказывается, в больших компаниях типа Google и Facebook собеседования далеко не такие качественные, как можно было бы подумать :(
В частности, я был крайне удивлен что проведение технических собеседований доверяется обычным программистам без серьезной подготовки их для этой работы. И они приносят собственновыдуманные вопросы, скорее всего не прорецензированные более опытными коллегами... В итоге имеем что имеем: например, требуют писать код на доске (whiteboard), задают алгоритмические задачки олимпиадного типа и прочую чушь, с которой обычный программист никогда не имеет дела в реальной жизни (в том числе они сами). В итоге собеседование превращается в экзамен и приводит к огромному числу неправильных оценок кандидатов, причем ребята из Google утверждают, что это исключительно "false negative", тогда как я почти уверен, что "false positive" там тоже немало.
Я давно интересуюсь собеседованиями, и есть кое-какой опыт в этой области, причем побывал на обеих "сторонах баррикад": составлял вопросы и проводил собеседования когда работал в Softline; ну и конечно приличное количество раз ходил собеседовался в разные компании - в Костроме, Москве, Питере и Хельсинки, включая например Microsoft (кстати, за последние 5 лет не услышал ни одного отказа: 100% собеседований были успешными и заканчивались предложением работы).
Итак, ниже мои мысли по тому что нужно проверять на собеседованиях и как, и что не нужно, и почему.
Часто возникающая задача – это прикрутить к ячейкам JsGrid контекстное меню с некоторыми дополнительными функциями. Мой любимый пример – это контекстный фильтр, когда кликаешь по ячейке правой мышой, и жмешь фильтровать по значению ячейки. Очень удобно.
В прошлом посте я объяснял, как устроена система событий JsGrid, и оказывается, как раз с помощью события SP.JsGrid.EventType.OnRightClick - можно решить задачу с контекстным меню. Помимо события, впрочем, надо еще уметь само контекстное меню создавать. И оказывается, JsGrid имеет API и для этого тоже!
В предыдущей статье я описывал, как осуществляется подсветка строк и отдельных ячеек в JsGrid. Но если вы попробовали использовать это решение, вы наверняка заметили одну недоделку: подсветка не обновляется при редактировании соответствующего значения.
Да, к сожалению, JsGrid это вам не KnockoutJs, так что обновлять придется самостоятельно. Впрочем, делается это очень легко.
В этом посте я расскажу про систему событий в JsGrid: как подписываться на события, какие интересные события JsGrid предоставляет, и приведу пример про обновление подсветки строки после редактирования ячеек этой строки.
Тружусь сейчас над TypeScript-дефинишенами для JsGrid. Работа долгая и тяжкая: для каждой-каждой функции в JS файле из 24.5k строк нужно определить типы параметров и возвращаемого значения, понять что эта функция делает, и все это описать. Потратил уже несколько дней, по 5+ часов, и пока еще только в начале пути... Между прочим, даже главный шарепойнтовский файл, SP.debug.js, имеет меньший размер - ~21k строк...
SharePoint особенно знаменит затыками "на последнем километре" и багами в совершенно неожиданных местах. Поэтому чем больше решение тестируется, и чем раньше начинаешь тестировать - тем лучше.
Однако, тестировать SharePoint-решения не так-то просто. Их ведь надо еще задеплоить. А пока деплоишь, заснуть можно!... И потом сиди вспоминай, что вообще протестировать-то хотел...
И ведь все знают, что нередко бывает так: правишь пару символов - это занимает буквально секунды, и потом деплоишь пять минут, чтобы посмотреть результат. Потом видишь что не помогло - и по новой, еще пять минут деплоя... И не думайте, что концентрация от этого не теряется. Еще как.
Смешно сказать, но я до сих пор вспоминаю SPVisualDev, расширение для Visual Studio для работы с SharePoint 2007. Мгновенное развертывание в 12 hive, отличная поддержка удаленной разработки и отладки, всё удобно, быстро и просто. Этого в SharePoint Developer Tools нет и в помине даже сейчас, в 2014!...
Да, к сожалению, SharePoint с точки зрения скорости разработки сильно далеко от того, что сейчас происходит во "внешнем мире". А происходит, к слову, там, вот что:
Тем временем во "внешнем мире"...
Проект IDE Light Table набрал $300k на Kickstarter. Основная идея проекта - в "живой разработке", когда IDE всегда находится в режиме отладки (!). Т.е. обычного режима не-отладки просто не бывает. Только начали писать код - тут же можно смотреть состояние переменных, и т.д.
Многие современные IDE поддерживают режим "live development". Пример - опенсурсная IDE Brackets. Вот одноминутная демка:
Visual Studio и ASP.Net развивают проект "Browser Link". Идея состоит в том, чтобы инжектить Signal-R скрипт на страницу, что позволяет в дальнейшем этой страницей управлять: релоадить целиком или частями, изменять, и т.д. "Browser Link" можно расширять с помощью Visual Studio extensions. В составе Web Essentials есть несколько крайне интересных расширений такого плана. Скотт Хансельман в этом 4х-минутном видео подробно все это демонстрирует:
Visual Studio "14" CTP 4 по умолчанию использует open source компилятор Roslyn, который имеет расширенные средства для работы с неполными синтаксическими деревьями, благодаря чему им удалось сделать on-fly incremental compilation. Идея в том, чтобы пропустить шаг Build. Т.е. меняем код, сохраняем, переходим в браузер, F5 - и смотрим изменения.
Помимо общеизвестного jsFiddle, появляется все больше и больше других Fiddle'ов, крайне интересных! Например, проект dotNetFiddle не только позволяет писать C# код онлайн, но также предоставляет режим, в котором можно тестировать полномасштабное ASP.Net MVC приложение (выберите Project Type: MVC)!
И т.д., список можно продолжать. Но я думаю вы поняли идею: все осознают, что чем меньше задержка между написанным кодом и увиденным результатом, тем лучше. И к этому идут. Но что можем сделать мы, SharePoint-разработчики?
Оказывается, и в SharePoint тоже можно сделать немало!
Для начала, продолжая мысль из поста про скрытую прелесть provider-hosted Apps, ну как бы все современные вещи можно там использовать без ограничений :) Так что всё что выше описано, нам по большому счету тоже доступно. Надо просто не забыть воспользоваться.
Во-вторых, кратко вернусь к SPVisualDev. Это open source расширение было написано ОДНИМ человеком в 2008 году. Получается, не настолько уж это и сложно?... ;)
Дальше. Давайте подумаем про BrowserLink. Можно ли что-то похожее использовать в SharePoint? Я думаю - да. Ведь BrowserLink это ни что иное, как банальный SignalR. Если заинжектить аналогичный SignalR скрипт в masterpage SharePoint-сайта, то мы получим точно такое же "живое" соединение Visual Studio и SharePoint. Я думаю можно просто выдрать из страницы то, что Visual Studio инжектит, и запихнуть в SharePoint, и оно будет работать. Не успел проверить пока.
Дальше. А что насчет jsFiddle и ASP.Net MVC fiddle? Можно ли сделать собственный SharePoint fiddle? ДА БЕЗ ПРОБЛЕМ! Вот например оцените, проект JSON fiddle:
Опять же. Сделано буквально на коленке, какой-то мужик посидел пару вечеров и написал. Вы, дорогой читатель, тоже могли бы такое написать, даже в одиночку. И вас, дорогие читатели, смею заметить, дофига.
Моя попытка: CamlJs-Console
Вообще, на удивление, многие вещи не настолько сложные, как кажутся. Примерно в середине сентября я начал работать над крайне интересным проектом под названием CamlJs-Console. Это расширение для хрома, позволяющее создавать CamlJs-запросы в режиме live development, очень похожем на пример выше про Brackets. Пишешь - и сразу же видишь результат.
Оказалось, что Chrome Extensions пишутся на HTML+CSS+JavaScript. Очень просто. При желании можно даже создавать Chrome Extension + Web App (или даже SharePoint App) из одного исходного кода...
БЛИН! Я когда только-только сделал самую первую версию у себя на локальной машине в 3 часа ночи :), я сидел тестировал и не мог остановиться. Это настолько отличалось от вот этого "поправил-5 минут деплой", что чувствовалось как магия какая-то. Серьезно :)
Общий вид:
А вот live preview данных из списка:
Мне даже удалось подцепить туда интеллисенс (на основе TypeScript Language Service - ведь как известно, TS является расширением над JS, т.е. любой валидный JS-код является также и валидным TS-кодом):
И более того, мне даже удалось сделать интеллисенс лучше, чем TS-интеллисенс в Visual Studio! Потому что ведь у меня были живые списки. И их поля... :)
Мне кажется, получилось здорово! И заняло каких-то пару недель, причем большую часть времени возился с интеллисенсом.
Преимуществ у Chrome Extension немало: не надо аутентифицироваться, не надо ничего ставить на сайт (в отличие от того же SharePoint App). Можно тестировать и онлайн сайты, и на dev виртуалке, и что особенно ценно - зайти на production и там проверить запрос, на реальных данных (!). Интеграция работает через JSOM, но можно реализовать вариант на веб-сервисах (через SPServices например), и тогда будет работать даже с SharePoint 2007 (сейчас только SP2010 и SP2013).
Что дальше?
Ооооо... у меня полно идей, просто миллион! Можно делать extension'ы наподобие CamlJs - для работы с конкретным API, решения конкретных проблем. Можно делать более широкопрофильные, наподобие JSOM fiddle, но именно в виде Chrome extension. Можно копать в сторону интеграции Visual Studio и SharePoint, создания чего-то похожего на BrowserLink. Можно подумать о гибридных решениях, Visual Studio -> Chrome Extension -> SharePoint.
И это все может значительно улучшить наш процесс работы с SharePoint. Значительно!
Коллега с работы делает сейчас потрясающую штуку, как раз под впечатлением от CamlJs-Console. Крайне легко делается, но возможности открываются потрясающие. Смысл в том, что в Chrome через F12 можно редактировать файлы, подгруженные на страницу. Но конечно эти изменения никуда не сохраняются. Ну а вот он сделал так, что сохраняются, обратно в SharePoint :) И кода там - 50 строк :))). Проект пока на супер-начальной стадии, поэтому если захочется потестировать, тестируйте аккуратно и только на dev-окружении please :) Ссылка вот.
Заключение
Я из всей этой истории главное вот что понял: все в наших руках. Не надо ждать MS или еще кого. Мы сами можем.
P.S. Если у кого есть идеи/мысли на этот счет, с удовольствием поучаствую в обсуждении - кидайте комментарии! :)
