Category Archives: SharePoint

SharePoint Conference North America thoughts and slide links

1 Reply

What a fun few days hanging out with friends and collegues in Las Vegas for the last few days. SPC NA seemed to go pretty well! I think the biggest thing for me this week was being surrounded by people who all share a common passion. That is what SPCs in the past were great at and i think some of that was rekindled this week. As always wandering the expo floor and talking with other vendors about what they are building is my favorite thing about conferences and this week was great for that. Some new faces popped up too!

For those looking for my slides from the session i did you can find them below. Unfortunatly there is a lot of content in the demos that isnt captured in the slides, but i hope it helps.

Office 365 development Slack

Leave a reply

imageMany years back a small group of friends started the Office 365 developer slack network.  A bunch of people joined and then it rapidly went nowhere Smile

I think that is a crying shame. 

I recently joined a Slack network for Kubernetes and its a fantastic resource for asking people questions, working with others on issues you are having and generally learning and finding things.

Office 365 development has changed a lot over the years and people are finding new ways of doing things all the time. The Microsoft Graph is taking off in a HUGE way, SPfx is becoming a viable way to build on the SharePoint platform, Azure AD is the center of everything in the cloud for MS and the ecosystem is heating up with amazing new companies and products springing up.

Anyway … I miss having a Slack network for Office 365 development chats with people.

You can join the O365 Dev Slack here if you feel the same way …

http://officedevslack.azurewebsites.net/

-CJ

RunAsRadio: Keeping Active Directory Data Up to Date with Chris Johnson

Leave a reply

I recently sat down with Richard Campbell on the RunAsRadio podcast to talk about the state of directories, why people profile data is a critical component of SharePoint and Office 365 deployments and how Hyperfish can help organizations with their profile and directory mess.

Listen here: http://www.runasradio.com/Shows/Show/508

Features I would add to SharePoint 2010

Leave a reply

Not a typo in the title 🙂

Back in 2007 I was looking to move to the US and join the SharePoint engineering team.  As part of the early initial email based discussions about the role the guy I was talking to about a job asked me to list off some things I think were needed for SharePoint development.

I recently stumbled on the OneNote page where I was jotting down some notes before I sent him the email.

Here they are in all their 2007 glory (verbatim minus the bolding):

  1. Remotable APIs … Or API set that wraps the Web Services
  2. Integration of the FrontPage RPCs into the OM
  3. Web Services that take/return object friendly OM friendly data …datasets etc…  + keep XML document based ones.
  4. Ability to create “strongly typed” objects from SharePoint objects… Like strongly typed datasets

Here is my take on where we ultimately ended up for each of these:

#1 – Remotable APIs … this would become the Client Side Object Model in SharePoint 2010.
#2 – FP RPCs … this would be the ability to better interact with files and folders etc… via the CSOM.
#3 – Web Services with friendly data – this would become the first ListData.svc REST/OData endpoint in SharePoint 2010.
#4. – Strongly typed objects – this would become the work we did on Linq to SP  and SPMetal

Finding these notes was pretty nostalgic really!  It’s hard to imagine development in SP without some of these things now … especially the REST services considering how far they have come now!

It’s also interesting in that these were really the first investments in helping developers get code off the SharePoint server. Before this as a developer you really had to create and deploy your own web services and use the SP server side object model (yuck!).

What would be the four things you would write on your list today? Comment below!

Office 365 – Developer and Ecosystem team update

Leave a reply

The 10th of June will mark 3 months since I returned to Microsoft.  It’s fair to say it’s been a major whirlwind!

Coming back to a company is a funny thing. A lot is the same, but so so much is different. I am on the Office 365 team and there are many familiar faces from my previous time at Microsoft, but so many new ones too.  It’s great!  The team rocks, the group rocks and the product(s) are the best in the world.

I lead a small team (me + four others) called the Office 365 Developer and Ecosystem team.  Our goal is to care about developers who want to building on our technology.  The team is made up of amazing superstars, namely Dave Pae, Jeremy Thake, Sonya Koptyev and <to be hired> (this TBH is not a superstar since they don’t exist yet).

So what have we been up to you may ask?

All sorts of things! 🙂  Primarily the team have been planning for the 12 months. We have lots of things to accomplish and we have been working out what the big priorities will be, who will tackle them and what we need to do to make it all work.

Roughly those things fall into these big high level categories:

  • Develop a great Office 365 ecosystem (developers and partners)
  • Train developers
  • Move solutions/product in the cloud
  • Community engagement

The first one is all about building an amazing set of partner companies that have products and services for Office 365. The Ecosystem. We make sure individuals and companies have all the things they need to be successful.  That includes understanding what is possible, why they would want to build for Office 365, how to do it and how to attract customers and build a great business. We have been working with our Developer and Platform Evangelism (DPE) counterparts to work out how they will help us scale out to touch thousands of developers and ISVs this coming year to train them on building for Office 365 and building great solutions and products for it.  We have an amazing set of partners building Apps, Products and Solutions for SharePoint and Office 365 already, but we want to ensure they are successful both in a technical sense and a business one which will grow a healthy and vibrant partner ecosystem.

Next its all about training developers.  We hear all the time that it’s too hard to find skilled developers. We aim to do this via a number of channels such as the Microsoft Virtual Academy, Ignite training events, Developer Camps, Channel 9 and conferences worldwide.  The team don’t necessarily do it all themselves!  We work with lots of people both inside Microsoft and outside to design, develop and deliver all the developer training material we need and then push it out to people through all those channels.

We know that LOTS of customers (> ~80% in the case of SharePoint) have customizations or custom code they have made on premises and that for them to move to the cloud they need those things plus many of the ISV solutions they rely on today.  We are working hard on making sure that we have the guidance, tools and training for those who want to move now, or just want to start building those customizations in a way that will make it easier to move when they are ready down the line.  For some customers this will be a way off, and we know that, but for those that want to move now we would like to help them do that.

Community is hugely important to us.  Not only in actual size, but also in importance.  We will be spending a lot of time engaging with people, talking about the issues they are facing and taking feedback.  This means you will see us presenting at conferences, participating in community activities online and generally just being “out there”.  The power of the SharePoint community came not from Microsoft, but from the participants and we don’t pretend that we can make a great community … but we can help support one.

Those are the big high level categories of things we will be working on.  That is by no means exhaustive, but it should give you an idea of what we are thinking about.

There are some more tactical things that we have heard a LOT of feedback about from developers and ISVs.  Namely a process around telling developers what is coming and when, so they can test their code and build new things based on new features coming.  All I can say for now is that we are working hard on this problem. We are going to publically have a plan of record that anyone can read to see what is in the pipe for developers. We are also running a closed small pilot to allow ISVs to get access to Office 365 tenants that get updates first. This means ISVs can test their products prior to the changes rolling out to all customers around the world.  Our goal is to one day be able to offer that to any customer, but for now it’s a small closed group to learn about what they need, how we manage the feedback/issues that come up and some of the logistics of the whole exercise.

There are of course lots of other things we are working on that we can’t talk about just yet and those will have to wait for another day 🙂

We have seen some incredible milestones in the past 3 months for Apps in Office 365 too:

  • > 1,000,000 launches a week of Apps for SharePoint in Office 365!
  • > 850 apps in the Office Store
  • 30 Ba ba Billion API calls a month

I hope this has given a bit of insight into what I have been working on since my return to MS 3 months ago.  We have SO much to do and really we are just gearing up for an amazing year ahead.  I couldn’t be happier with how things are shaping up.

Be sure to follow @OfficeDev for updates!

-CJ

SharePoint/Office 365 at Build 2014

Leave a reply

I’m heading to the Build conference next week in San Francisco, YAY my first //build ever.  We have a bunch of great developer related content for SharePoint and Office 365 there.  Don’t worry if you have not developed for SharePoint or 365 before, there is content to get you up to speed!

Here are the sessions:

Building Connected Productivity Apps Brian Jones
Office Power Hour – New developer APIs and features for Apps for Office Rolando Jimenez Salgado
SharePoint Power Hour – New developer APIs and features for Apps for SharePoint Rob Howard
SharePoint 2013 Apps with AngularJS Jeremy Thake
Building Enterprise Social Apps with Yammer Jose Juarez Comboni
The brand new OneNote service – reach the massive user base with your apps. Gareth Jones
Developing Office 365 Cloud Business Apps Dan Fernandez
Deep Dive into Mail Compose Apps APIs Andrew Salamatov

Also Office 365 will have a booth so come and visit the booth and connect with the speakers and the team from Redmond.

SharePint @ //build, Wed at 7pm @ Chieftain Irish Pub

see you there!

-CJ

Sandbox code is “deprecated”, long live the Sandbox

3 Replies

we have deprecated the use of custom managed code within the sandboxed solution – Brian Jones, Principal Program Manager, Apps for SharePoint

It’s been a long time coming and widely anticipated that this announcement would come at some point.  It’s great to see the announcement and the clarity many have been asking for.

I feel like I’m in a good position to comment on this and give some background about why I think deprecating code based sandbox solutions is good idea. I was on the SharePoint engineering team when the sandbox was being built and for a period of time I was the Program Manager for the feature.

Background:  Sandbox solutions in SharePoint were introduced in SharePoint 2010.  They allowed a packaged set of assets and code to the uploaded to a SharePoint site.  That can consist of declarative components like XML for adding things like List Templates, as well as compiled code for things like Web Parts or Event Receivers.

When the Sandbox was being designed and built it was about 2 – 3 years prior to SharePoint 2010 being released. Azure, and cloud computing in general, either didn’t exist or was in its infancy. SharePoint needed a way to upload customizations/components to SharePoint sites where the administrators were not comfortable with installing Farm Solutions aka. Full trust solutions. Microsoft itself was a perfect example of this.  If I built a web part I, as a Microsoft employee at the time, couldn’t load that onto our SharePoint sites that MS IT ran.  No 3rd party web parts or products. This was a common problem in many large organizations and we heard about this time and time again with customers.

Sandbox Solutions were the answer. They allowed users to upload a solution and have SharePoint run it while it being controlled, secured and run in a sandboxed process. The main thing this gave SharePoint was the ability to isolate the code in that solution and ensuring that if it crashed or was badly behaved that it didn’t break the rest of the SharePoint environment.

The problem was that Sandbox Solutions was a feature added in Windows SharePoint Services (WSS) and that was a different product from SharePoint Portal Server (SPS) that built on top of WSS.  The API set in the Sandbox that was available was limited to WSS APIs and even then only a subset of them. There were good reasons for this, but at the end of the day it was very limiting for people.  Ideally it would have been great to have lots of SPS APIs available too. But that didn’t happen (different story).

So that is the background about how/why Sandbox came about.

… now fast forward to today …

In a nutshell the Sandbox was a good solution to the problem faced when it was designed. However, it’s not a great solution to the problem given the technology we have today.

Why is it no good today you ask?

A lot happened after the Sandbox was designed and built.  Cloud computing took off, new advances in code in all sorts of places got easier e.g. isolated apps on a phone.  A lot was learnt. 

In short its my belief that SharePoint shouldn’t have been trying to replicate an isolated code hosting environment.  That is reinventing the wheel and there are other teams at MS who build products to do this extremely well already.  Namely IIS and Azure.

Think about that for a second.  Imagine being given some arbitrary code and told to run it, but doing it in a way that was safe, secure, manageable and fault tolerant.  It’s actually quite a tough challenge. If you say it’s easy then you should try doing it instead of talking about it 🙂 (tip with wider life applicability too)

So today MS clarified that SharePoint was getting out of the code hosting game.  Why?  Because it was limited and there are better solutions to this problem today. 

The new SharePoint app model is designed to solve this by moving “sandbox” code to an alternative host e.g. IIS or Azure or <insert thing that runs code here>.

Sandbox code might be “dead”, but the new app model IS the new Sandbox!

I see the reasons why the sandbox came about the same as I do for the new app model.  They are solving the same problem.  How do you allow someone to customize, extend and build new things on SharePoint without compromising the integrity of SharePoint itself?  That is the goal.

Today in SharePoint 2013 and Office 365 we have the ability to build solutions that use this new app model.  Sure, it’s not perfect in the APIs it provides and there is plenty of scope for adding things.  I am certain it will evolve to cater for more of these things over time.  That said, it is MUCH better suited for the long term.  I for one am loving the ability to use all the latest dev tools and technologies in Azure that were not possible in SharePoint previously.

The app model may not be applicable or possible to be used for everyone today and that is fine. It’s going to develop and that will change over time would be what I bet on.  But it is the right path moving forward.  This might cause some pain for people in the short term and I understand the frustration people have with changes like this. But I would MUCH rather have to deal with this change than be limited to a inferior set of capabilities in the longer term.  This is the right move long term (in my humble opinion).  Short term pain, long term gain.

Getting SharePoint out of the code hosting solution was the right things to do and I applaud the team for clarifying there position on this.

I look forward to the SharePoint Conference in March where hopefully (fingers crossed) we will hear more about the future of the new app model and how it will address its shortfalls today.

-CJ

SharePoint Saturday Chicago #SPSChicago

Leave a reply

Today I presented a 101 session on getting started with the new SharePoint App Model. It’s a lot to get through in 75mins, but hopefully it gave people enough to get started and try out building an app for Office 365 or SharePoint on premises.

Thanks to everyone that came along!  #SPSChicago is a great free event for people with a great lineup of speakers.

Here are the slides:

Content by Search webpart in Office 365

3 Replies

It looks like the much awaited Content by Search Web Part might start showing up in Office 365 tenants!  I’m not sure when this started, and it might not be on all tenancies just yet.

Here it is in all its search laden glory …

image

It seems to depend on what version your Office 365 tenant is.  If you have 16.0.0.2120 or above then you should be in luck.

To find out what version your tenancy is on log in and navigate to the following URL:

https://FooCorp.sharepoint.com/_vti_pvt/service.cnf

You should see something like this:

vti_encoding:SR|utf8-nl
vti_extenderversion:SR|16.0.0.2120

Update: MS has announced this now:  http://blogs.office.com/b/office365tech/archive/2013/10/29/search-innovations-for-site-and-portal-design-in-sharepoint-online.aspx

-CJ

SharePoint Online protects against BREACH

1 Reply

Back in August a co-worker who is doing a lot of work with Office 365 noticed something changed in Office 365.  One of those sneaky, unannounced changes that break things inadvertently and take a while to track down.

It turns out Office 365, SharePoint Online in particular, had stopped Zipping returned  payloads to JavaScript Object Model (JS OM or JSOM), even if you explicitly asked for them.  You can read about his initial discovery in a blog post.

TL;DR – Send a request for information from SharePoint, include the “Accept-Encoding: gzip, deflate, sdch” header, response comes back without compression applied.

Here is it in action.  To try this at home you will need:

  • One SharePoint Online site
  • A tool like Fiddler or PostMan (handy Chrome app) for easily handcrafting and initiating HTTP requests and seeing what comes back.  I’m using it below.
  • A list set up in your SharePoint site with some data in it

Create a HTTP GET request to return the items from your list. Something like this:

http://MySharePointOnlineSite.SharePoint.com/sites/Developer/_api/Lists/MoviesList/Items?$select=Title

Add your Accept-Encoding header and Accept headers like so to ask for JSON back and gzip compression:

image

Send your request and you should see some JSON come back.  Something like this:

image

Notice a distinct lack of zippage? Also if you flip to the Headers tab on the response you don’t see a Content-Encoding: gzip like this:

image

Now this isn’t really a big problem in the grand scheme of things.  Unless you are calling this from a mobile app where bandwidth is important or you need low latency replies. Another example would be if you are building a SharePoint App and calling the REST services to get back list data to drive some UI … you want it to be snappy.

After a bit of hunting my co-worker pointed me at a post about an SSL + HTTP Compression hack called BREACH.  Basically this hack lets hackers break SSL by fiddling with the input on a request and watching changes in the compressed response. After a few (say 1000) requests they can crack your SSL.  Note this is only an issue if you are serving content than can change based on manipulation of request data AND the return payload can be compressed.

The fix?  Turn off HTTP compression on responses.

Yes, really. That seems to be the only practical option for mitigating against this attack right now. No, this isn’t a bug in IIS or SharePoint or any other product.

Hence, this seems to be why SharePoint online no longer compresses responses.  I was told that static files might be compressed since they wont fall victim to this hack, however my testing didn’t surface any resources that I could make come back compressed. (Let me know if you find one)

E plan tenants  are the most effected I think as the SharePoint Online sites are all behind SSL.

I found this really interesting so I thought I would share.

-CJ

PS: thanks to my Microsoft buddies who helped confirm this for me.