воскресенье, 11 октября 2015 г.

Cisar

В этом году я сделал одну большую вещь - Cisar. Это встроенное в браузер (точнее в F12 DevTools) мини-IDE, предназначенное для создания CSR (Client Side Rendering) кастомизаций в SharePoint. Главная фишка Cisar'а в том, что он поддерживает Live Preview, т.е. набираем код и сразу же, в реальном времени, видим результаты его работы на странице.

Это позволяет работать очень эффективно и создавать решения по кастомизации форм буквально за считанные минуты. Не шучу. Был даже реальный случай: коллега на работе оценил некоторую задачу по кастомизации форм в час работы, там надо было заменить текстовое поле dropdown'ом, причем он (коллега) с CSR очень хорошо дружит. Я с ним поспорил на пиво, что смогу сделать за 3 минуты с помощью Cisar. Проиграл: сделал за 5 :)


Поддерживается CSR для:
  1. Форм списков
  2. Представлений списков
  3. Представлений списков в режиме Quick Edit
НЕ поддерживается на данном этапе CSR для результатов поиска, и вообще Display Templates как класс. Надеюсь это добавить в будущем, но это технически нетривиально.

До последнего времени Cisar плохо работал с не-root сайт-коллекциями, но у меня наконец-то дошли руки это поправить и теперь проблем быть не должно. Но версия все еще Beta, так что огромная просьба, всем кто будет использовать, пишите багрепорты!! Сюда в комментарии, или на GitHub, куда-нибудь в общем... :)

Cisar полностью бесплатен, open source, лицензия "Public Domain" (это означает, делайте вообще все что угодно с ним, никаких ограничений).

С технической точки зрения Cisar - это расширение для Chrome, написанное кстати на TypeScript. Для подсветки синтаксиса используется редактор codemirror. Для отображения списка файлов используется KnockoutJs. Для Live Preview используются результаты нескольких недель копания в кишках CSR, если вы думаете что это просто eval, можете посмотреть код :)

Исходники доступны на GitHub.
Само расширение можно скачать из Chrome Web Store.

Также, если кто-то вдруг пропустил мои статьи по CSR, с множеством примеров кастомизаций (большинство из которых были созданы с помощью Cisar), ссылки ниже (статьи на английском):
P.S. На самом деле так привык к Cisar, и так удобно, что теперь уже даже пытаюсь его использовать для любого клиентского кода. И как я раньше писал JSOM-код без intellisense!? :)

пятница, 9 октября 2015 г.

Про собеседования

Прочитал статью Get that job at Google, и очень сильно разочаровался! Ситуация подтвердилась и другими источниками: оказывается, в больших компаниях типа Google и Facebook собеседования далеко не такие качественные, как можно было бы подумать :(

В частности, я был крайне удивлен что проведение технических собеседований доверяется обычным программистам без серьезной подготовки их для этой работы. И они приносят собственновыдуманные вопросы, скорее всего не прорецензированные более опытными коллегами... В итоге имеем что имеем: например, требуют писать код на доске (whiteboard), задают алгоритмические задачки олимпиадного типа и прочую чушь, с которой обычный программист никогда не имеет дела в реальной жизни (в том числе они сами). В итоге собеседование превращается в экзамен и приводит к огромному числу неправильных оценок кандидатов, причем ребята из Google утверждают, что это исключительно "false negative", тогда как я почти уверен, что "false positive" там тоже немало.
Я давно интересуюсь собеседованиями, и есть кое-какой опыт в этой области, причем побывал на обеих "сторонах баррикад": составлял вопросы и проводил собеседования когда работал в Softline; ну и конечно приличное количество раз ходил собеседовался в разные компании - в Костроме, Москве, Питере и Хельсинки, включая например Microsoft (кстати, за последние 5 лет не услышал ни одного отказа: 100% собеседований были успешными и заканчивались предложением работы).

Итак, ниже мои мысли по тому что нужно проверять на собеседованиях и как, и что не нужно, и почему.

среда, 22 октября 2014 г.

Своё контекстное меню в JsGrid


Часто возникающая задача – это прикрутить к ячейкам JsGrid контекстное меню с некоторыми дополнительными функциями. Мой любимый пример – это контекстный фильтр, когда кликаешь по ячейке правой мышой, и жмешь фильтровать по значению ячейки. Очень удобно.

В прошлом посте я объяснял, как устроена система событий JsGrid, и оказывается, как раз с помощью события SP.JsGrid.EventType.OnRightClick - можно решить задачу с контекстным меню. Помимо события, впрочем, надо еще уметь само контекстное меню создавать. И оказывается, JsGrid имеет API и для этого тоже!

вторник, 21 октября 2014 г.

Система событий JSGrid

В предыдущей статье я описывал, как осуществляется подсветка строк и отдельных ячеек в JsGrid. Но если вы попробовали использовать это решение, вы наверняка заметили одну недоделку: подсветка не обновляется при редактировании соответствующего значения.
Да, к сожалению, JsGrid это вам не KnockoutJs, так что обновлять придется самостоятельно. Впрочем, делается это очень легко.
В этом посте я расскажу про систему событий в JsGrid: как подписываться на события, какие интересные события JsGrid предоставляет, и приведу пример про обновление подсветки строки после редактирования ячеек этой строки.

понедельник, 20 октября 2014 г.

Выделение цветом важных данных… в JSGrid!

Пока дефинишены пишутся, решил написать про некоторые простые методы работы с JSGrid, на примере подсветки данных в гриде.

Также в статье приводится довольно много сведений общего плана про JsGrid, которые очень важны для понимания, как это все работает.

вторник, 14 октября 2014 г.

Документирую SharePoint JSGrid

Тружусь сейчас над TypeScript-дефинишенами для JsGrid. Работа долгая и тяжкая: для каждой-каждой функции в JS файле из 24.5k строк нужно определить типы параметров и возвращаемого значения, понять что эта функция делает, и все это описать. Потратил уже несколько дней, по 5+ часов, и пока еще только в начале пути... Между прочим, даже главный шарепойнтовский файл, SP.debug.js, имеет меньший размер - ~21k строк...

Скриншот процесса:


суббота, 11 октября 2014 г.

Ускоряем SharePoint-разработку

SharePoint особенно знаменит затыками "на последнем километре" и багами в совершенно неожиданных местах. Поэтому чем больше решение тестируется, и чем раньше начинаешь тестировать - тем лучше.

Однако, тестировать SharePoint-решения не так-то просто. Их ведь надо еще задеплоить. А пока деплоишь, заснуть можно!... И потом сиди вспоминай, что вообще протестировать-то хотел...

И ведь все знают, что нередко бывает так: правишь пару символов - это занимает буквально секунды, и потом деплоишь пять минут, чтобы посмотреть результат. Потом видишь что не помогло - и по новой, еще пять минут деплоя... И не думайте, что концентрация от этого не теряется. Еще как.

Смешно сказать, но я до сих пор вспоминаю SPVisualDev, расширение для Visual Studio для работы с SharePoint 2007. Мгновенное развертывание в 12 hive, отличная поддержка удаленной разработки и отладки, всё удобно, быстро и просто. Этого в SharePoint Developer Tools нет и в помине даже сейчас, в 2014!...

Да, к сожалению, SharePoint с точки зрения скорости разработки сильно далеко от того, что сейчас происходит во "внешнем мире". А происходит, к слову, там, вот что:

Тем временем во "внешнем мире"...

  1. Проект IDE Light Table набрал $300k на Kickstarter. Основная идея проекта - в "живой разработке", когда IDE всегда находится в режиме отладки (!). Т.е. обычного режима не-отладки просто не бывает. Только начали писать код - тут же можно смотреть состояние переменных, и т.д.
  2. Многие современные IDE поддерживают режим "live development". Пример - опенсурсная IDE Brackets. Вот одноминутная демка:

  3. Visual Studio и ASP.Net развивают проект "Browser Link". Идея состоит в том, чтобы инжектить Signal-R скрипт на страницу, что позволяет в дальнейшем этой страницей управлять: релоадить целиком или частями, изменять, и т.д. "Browser Link" можно расширять с помощью Visual Studio extensions. В составе Web Essentials есть несколько крайне интересных расширений такого плана. Скотт Хансельман в этом 4х-минутном видео подробно все это демонстрирует:

  4. Visual Studio "14" CTP 4 по умолчанию использует open source компилятор Roslyn, который имеет расширенные средства для работы с неполными синтаксическими деревьями, благодаря чему им удалось сделать on-fly incremental compilation. Идея в том, чтобы пропустить шаг Build. Т.е. меняем код, сохраняем, переходим в браузер, F5 - и смотрим изменения.
  5. Помимо общеизвестного 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. Если у кого есть идеи/мысли на этот счет, с удовольствием поучаствую в обсуждении - кидайте комментарии! :)