Published: April 18, 2024
Last Update: April 18, 2024
Owr very own Camilo Dominguez presented us on our bbtechies session on Wednesday April 17th 2024 the Public REST API roadmap and a bit of the Developer Portal Roadmap.
Here is the slide deck!
Cheers!
Published: March 15, 2024
Last Update: March 15, 2024
Ensuring prompt email support is crucial for achieving a seamless integration. We prioritize addressing inquiries from developers and the community promptly. However, given the volume of emails we receive daily, ranging from straightforward queries to those requiring in-depth research for the best solution or alternative, our response times may vary. Our approach to supporting email inquiries involves several phases:
Upon receipt, emails undergo the following process:
Below are the recommended best practices to ensure you receive the quickest, most accurate, and highest quality response:
Ensure a Clear Subject Line:
Provide Relevant Information:
Be Concise Yet Specific:
One Issue per Email:
Maintain a Polite and Professional Tone:
Follow Up Appropriately:
We eagerly anticipate receiving full support and collaborating with your teams to ensure a successful integration.
Cheers!
Today, we had a really nice session with Mark O'Neil where he explored our roadmap for REST APIs and Developer Portal!
Have a glimpse of what's to come!
our forward looking statement must be kept in mind in this presentation
Here is the slide deck!
Cheers!
Today, we had a really nice session with Mark O'Neil where he explored our roadmap for REST APIs and Developer Portal!
Have a glimpse of what's to come!
our forward looking statement must be kept in mind in this presentation
Here is the slide deck!
Cheers!
Anthology has designed it's model for integrations in a manner which, when executed following our best practices, improves the Customer Integration Experience. Our goals in this area are multi-fold, yet all drive toward the best experience possible when Customers license, purchase, or develop integrations for enhancing their Anthology Products as campus differentiators and enablers in achieving their Teaching and Learning objectives for their Staff, Faculty, and Students.
Customer experience is important for Partners and Anthology Customers for many reasons. Most notably:
Customer Retention: Providing a positive customer experience can help improve customer retention rates. Customers are more likely to remain loyal to a brand if they have had a positive experience with the company.
Brand Reputation: A positive customer experience can enhance your company's reputation and help build a positive brand image. Word of mouth and online reviews are powerful marketing tools, and customers are more likely to share their positive experiences with others.
Competitive Advantage: Providing a superior customer experience can set a business apart from its competitors and give it a competitive advantage.
Overall, a positive customer experience is essential for building strong customer relationships, increasing customer loyalty, and improving the overall success of a business. This applies to our developer community as well as Anthology.
In addition to the general integration functionality, for which the integration development team is ultimately responsible, the most significant impact on the Customer Experience is installation and support of your integration.
Installation of your integration is often the first experience customers will have with your business and first impressions are lasting and influence future interactions.
How clients discover and know whom to contact for Support is also a significant influencer of impressions of your business.
Anthology has built our integration experience and best practices, with these latter two concepts in mind.
Anthology has thought long about how to simplify the integration experience for customers in the world of SaaS. In doing so we arrived at a "Register once, deploy everywhere" model for Integration developers to deliver theirr solutions. This applies to LTI 1.3 and RESTful integrations alike, and greatly simplifies installation for our mutual customers.
In prior years you may have built integrations which ran on-prem or in-process alongside the Anthology product. This required customers to manage the software themselves. Under the more modern SaaS model, which is used by Anthology, the customer is no responsible for updating and maintaining the integration, as SaaS product consumers receive updates automatically.
To facilitate the SaaS model, the Anthology Developer Portal provides the means for you the Developer to register your integration once and deploy to multiple customers. Once your integration is registered in the Developer Portal an identifier is issued - this identifier is used by all customers to install your integration.
This means you have one instance of your integration and all customers use that instance. This of course imply some design concepts for your integration.
This model for delivering innovative solutions to customers provides cost savings and improved efficiency for your business. This is because instead of multiple instances (with per instance charges accrued) you only need one instance of your integration which is shared by all your customers. This is the SaaS way.
Register once and Deploy anywhere means there are some differences in how you design and deliver your integration.
Note: The following pertains to development of integrations which are marketed to multiple customers. Only point 1 is pertinent to those who are developing campus-only solutions.
Each of the above enable you to deliver a secure, efficient, and postive experience to customers at a cost savings of single instance vs multiple instance service delivery.
There are really two types of Developer Portal accounts:
See Getting Started with the Developer Portal for more information.
See our Releasing your Integration guide for production release details.
Also see LTI Registration and Deployment with Learn guide which describes Anthology's approach behind releasing LTI 1.3 integrations.
It is the integration developer's responsibility to provide the necessary documentation for a successful installation. This is greatly simplified when following our best practices for Register once, deploy anywhere.
Currently there are three things which will generate no end of consternation for customers which degrades their experience with your integration/company. These three things fall into two groups User Roles and Support.
Aside from it not being a best practice to ask your customer to register your integration on the Developer Portal on your behalf, even worse is asking them to do so and then ask that they give your integration an Admin Role. Never, never, never ask them to do these terrible things.
Instead, develop your integration following the Register once model, and hand off your integration Identifier to your customer. If you are an LTI 1.3 provider - you are done. Your customer adds your LTI integration and sets availability to their users and they are done. No passing around of Keys and Secrets or error prone multiple copy pasting of multiple configuration strings... you hand off one integration Id which you get when you register your integration on the portal and done.
Well almost... the current exception (see The Future is Bright(er) below) is if your integration uses our REST APIs. Then your integration documentation must provide Anthology administrators with a list of privileges that need to be added to the user which is associated with your integration. The APIs list entitlements, not privileges, and therein lay a problem for Customers.
As the integration provider you want a great customer experience so you use the bookmarklet tool to determine the privileges you include in your documentation to provide guidance to admins installing your integration.
It probably goes without saying, but the integration vendor is responsible. Not Anthology.
When the vendor registers in the Developer Portal they provide email information which is seen by customers when they install the integration. That is why this email and contact information must be publicly reachable. That is also why it makes sense to have a specific account from which all your integrations are delivered.
See Getting Started with the Dev Portal for information.
Forward Looking Statement applies:
Statements regarding our product development initiatives, including new products and future product upgrades, updates or enhancements represent our current intentions, but may be modified, delayed or abandoned without prior notice and there is no assurance that such offering, upgrades, updates or functionality will become available unless and until they have been made generally available to our customers.
To ensure an optimal customer experience we have a few items which we intend to deliver in 2023. Each of these enable the offset the heavy lift of the installation of any integration from customers to the developer.
Integrations using the REST API require association with a REST integration user who has the necessary system role privileges (never a System Administrator Role!!!).
The REST APIs identify with entitlements while the systems identify with privileges. This complicates installation of REST integrations not using Three Legged OAuth (3LO).
Late 2023 we intend to release a "manifest" model for integrations which, amongst other useful data points, identifies the entitlements required by an integration. This manifest will be used on Administrator request to install an integration to display important information about the integration to the Administrator - notably the privileges requested by the integration developer.
The now informed Administrator may choose to install the integration at which time the REST integration user is created with the necessary privileges.
No interaction on the part of the Administrator other than reviewing and accepting the installation!
Currently LTI 1.3 and REST APIs use two separate authentication models. LTI 1.3 uses JSON Web Tokens (JWT) and REST uses OAuth 2 basic authentication using Key:Secret pairs.
Late 2023 the use of JWT will be optional for REST API-based integrations and JWT will be used exclusively for LTI 1.3 integrations which also use our REST APIs.
This greatly simplifies the development of LTI 1.3 integrations which use our REST APIs. The optional use of JWTs for non-LTI integrations provide an improved security model for REST API-based integrations while being backward compatible with existing REST integrations.
We will be adding sessions here as soon as we get the presentations! If you want to see your DevCon presentation, please write us at developers@anthology.com. All times are in ET.
Day 1 @ DevCon 2022
⏲ 1:00 PM - 1:45 PM Session
Creating a proof of concept for an integration from scratch can be tedious, there are many basic elements such API authentication or logs that will need to be sorted out before being able to work on meaningful code, and even then, lots of code will need to be written and tested for API Requests. This library abstracts the common and boring operations that Blackboard developers face when interfacing with the REST API so they can focus their effort in creating the cool features they need for their integrations. This library is intended to explore Blackboard REST APIs and to help create POCs for integrations. Please note this tool is not supported by Blackboard and no warranties of any kind are provided. In this presentation you will get to know the Bb_rest_helper library, and how to set up with Visual studio code and Jupyter notebooks to make the REST of your life easier
The Bb Rest Helper includes 5 classes to simpilfy common API operations with Blackboard APIs;
Day 2 @ DevCon 2022
⏲ 11:40 AM - 12:25 AM Session
⏲ 1:45 PM - 3:00 PM Session
⏲ 4:15 PM - 5:00 PM Session
Day 3 @ DevCon 2022
⏲ 11:30 PM - 12:15 PM Session
For years, many of us have relied on Building Blocks as a way to add features and functionality into our Blackboard Learn courses. One of the best tools we ever used was the javascript Hacks tool, which leveraged the renderingHook function to allow a system administrator to further modify and customize their Learn environment with custom tools, banner, footers, etc. Unfortunately, the Ultra experience no longer supports the renderingHook function, removing the key mechanism for these customizations.
In order to restore some of these capabilities, Blackboard Learn implemented a new feature set called the Ultra Extension Framework (UEF). This new framework opens a number of doors for developers to once again customize and extend their Blackboard Learn environments after switching to the Ultra experience. The Ultra Extension Framework consists of two key components – telemetry data for user activity, and injection points to add content at various locations within the Ultra interface.
The telemetry data can include a number of different events, including hover, click, route, as well as portal windows being created and removed. After initially launching as an LTI tool, an UEF tool can subscribe to any number of these events, and typically runs as javascript inside of a hidden iframe within the Ultra interface. From there, the custom script can then submit requests to the Ultra interface to create new panels, banners, notifications, popups, or even a custom help provider.
The attached presentation will provide some sample code snippets from projects that we have deployed in our production environment, including banners and custom help providers.
⏲ 9:00 AM - 9:45 PM Session
In this session Mark will give best practices for integrations that use LTI 1.3 and/or the Blackboard Learn REST APIs. There are many ways to improve your integration's performance and use, beginning with registration on the developer portal through the day it's installed on client systems. Given Mark's extensive experience working with 3rd-party integrations, he's selected those commonly missed best practices that, when you use them, will position your integration for maximum success.
When we started supporting LTI 1.3/Advantage (back in May of 2019) we chose to generate public/private key pairs for the tools. The tool vendor was then responsible for copying and storing those values on their side.
But the IMS Global community has moved away from that model and now suggests that tool vendors generate their own key pairs for LTI authentication and provide their public key via a JWKS URL. This model is more secure because there is not copying of a private key and allows the LTI Tool provider to follow best practices with key rotation.
We decided to follow that suggestion. If you want to register a new tool with Learn, you have to provide the JWKS URL information. And if you have an existing tool that use the Anthology-generated private key, please keep in mind that we'll be terminating support in the near future.
NOTE: Once you've made the change, you must have our mutual clients redeploy your LTI 1.3 tool. Redeploy means the following:
Follow the above steps exactly. Do NOT have them delete the integration as that will destroy all existing links to your tool, which can not be recovered.
Here is a video explanation of both the steps you need to take to update your tool's JWKS URL and the step you will need to have our mutual clients take. Note that after you update your tool's JWKS URL on the developer portal our mutual clients will NOT able to use your product until after they redeploy as described above and in the video.
FAQ:
As always, if you have any questions, check out the contact us page and let us know!
*Statements regarding our product development initiatives, including new products and future product upgrades, updates or enhancements represent our current intentions, but may be modified, delayed or abandoned without prior notice and there is no assurance that such offering, upgrades, updates or functionality will become available unless and until they have been made generally available to our customers.
In testing with the Google Canary Chrome Browser, one of our clients discovered an issue that was blocking users from logging in to their Learn instance. After much troubleshooting, we discovered a multi-layer issue that brings us to, you guessed it, cookies.
This affects clients in SaaS with Ultra Base Navigation enabled using Ultra integrations that rely on UEF
Here is a brief description of the contributing factors:
First, the client had built a custom Ultra login page. The page included code designed to ensure that Learn login pages would never render inside of an iframe within Learn. It looks like this:
if ( top != self )
{
top.location.replace( self.location.href );
}
In and of itself there's nothing wrong with it. We, at Anthology, have removed it from the default Ultra login page, but many clients use it in Original login pages, and so it's moved with them into Ultra.
If you are unsure whether you have a custom login page, visit help.blackboard.com for more information.
Secondly, when a user logged in, Ultra Extensions automatically fired off an LTI launch to UEF-enabled tools. The way UEF works is: after the LTI launch is validated, the tool redirects to the Learn REST endpoint to initiate a UserAuth flow. In our documentation, we call this a Three-Legged OAuth or 3LO. In most cases, it's a process that relies on a session cookie to hold everything together. This impending release of Chrome (and other browsers) will block this cookie because everything is happening across domains and involves the use of iframes.
So what happens is that, even though the integration is configured in Learn to not force the end-user to authorize the integration, the lack of the session cookie means that Learn has no idea that this user is logged in, so it pops open the login page.
Remember that code snippet above in the custom login page? Well, that takes over the entire browser page with the Learn login. And when the user logs in again, it renders the JavaScript meant for the UEF iframe into the page. In other words, it overtakes your Learn browser session. There is no way to actually get past that screen.
Related, this same issue affects Safari users when cross-site tracking is disabled.
Well, that depends upon who is reading this blog. If you are an administrator trying to get your users back in Learn, the most immediate fix is to remove that snippet from your login page. It won't fix your broken UEF integration, but it will at least let your users log in and interact with Learn.
If you are a developer that has built a UEF integration, we actually implemented a fix for this in April: a way to bypass the need for a session cookie in this process. In the LTI launch, we now provide what is called a one-time session cookie. This is present in both LTI 1.1 and 1.3 launches.
If you are using LTI 1.3, there's a small bug in this. I will share a workaround that will both get around this bug, but not fail when the bug is fixed.
This one-time session cookie is added to the claims in the LTI 1.3 JWT and the form POST parameters in LTI 1.1. You can grab that value from the LTI launch, return it as a parameter in your 3LO authorization code request, and your problem will be solved.
In LTI 1.3, you will see the value in the https://blackboard.com/lti/claim/one_time_session_token claim. This token is made up of a specially generated token value. It should also be followed by a comma and the user's UUID. The bug is that the comma is missing. Luckily, the user's UUID is the sub token in the same set of LTI claims. We intend to fix this, but to ensure your code works both now and after the fix, you can simply look for the comma. If it's not there, append it and the sub and you will be off and running. Here's a Python 3 code snippet to illustrate how this might look. We will be updating our UEF sample code, but at the time of this writing, we have not done so.
# Get the value of the one time session token from the LTI claim
one_time_session_token = message_launch_data['https://blackboard.com/lti/claim/one_time_session_token']
# If there is no comma in the value, we've hit the bug. Add it and the user's UUID
if "," not in one_time_session_token:
one_time_session_token += "," + message_launch_data['sub']
# Add the one_time_session_token to the query parameters to send to the Authorization Code endpoint
params = {
'redirect_uri' : Config.config['app_url'] + '/authcode/',
'response_type' : 'code',
'client_id' : Config.config['learn_rest_key'],
'one_time_session_token' : one_time_session_token,
'scope' : '*',
'state' : str(uuid.uuid4())
}
# Encode the parameters
encoded_params = urllib.parse.urlencode(params)
# Redirect the successful LTI validation to the Authorization Code endpoint
return(redirect(learn_url + '/learn/api/public/v1/oauth2/authorizationCode?' + encoded_params))
By now, I hope you are using LTI 1.3, but I know many are not. As a result, we also added a one-time session token to LTI 1.1 launches. This will come in the form POST parameter ext_one_time_session_token. Just like in the 1.3 example, your application should take this value from the LTI launch, append it to the authorization code request endpoint as one_time_session_token=that_token and redirect them to the authorization code endpoint.
We have validated this fix with one of the partners that was affected. If you are a developer, please fix the issue immediately! If you are an administrator of a Learn SaaS instance using Ultra, and you have UEF integrations, make sure you do not have that JavaScript snippet on your login page. And if you do, please remove it. Then let your UEF integration partners and developers know that this fix must be made as soon as possible.
Regardless of whether you are an administrator or a developer, please feel free to reach out to us at developers@anthology.com with any questions.
Happy coding!
First, as our documentation states, a Learn admin should never be told to associate a user with Learn admin privileges with any REST API integration, see this document. Hence we often get questions from folks on how to create a user to associate with a REST API integration that has limited capability on a Learn system. One way is to research and design your REST application to use OAuth 2 3-legged Authentication. See the documents referenced below. 3LO guarentees that the user using your REST Application can only do what they can do via the Learn UX when they are logged into Learn.
However, if your application is using our OAuth 2 2-legged Authentication read on. Or I should say, watch on. I created the following to answer the question "Is it possible to create a user that has only the necessary permissions and avoid using "Learn System Admin" user?"
The answer is yes! Here's a video explaining exactly how to proceed.
Reference Documentation:
We have spent some time over the holiday break updating and organizing our documentation better. One of the longest outstanding changes was to update the Caliper event samples from 1.0 to 1.1.
I am pleased to announce that we have finally completed this project. The event guide is largely unchanged, but the individual events have all been updated to show current sample payloads from each event, allowing you to better anticipate the messages you will receive and better plan your storage and reporting requirements.
Over the next few weeks, we will be highlighting some of the other key updates that we hope will help ease the onboarding process for new developers and make finding exactly what you need when you need it for everyone.
Happy Coding!
Back in the day, January 4, 2019 to be exact, Blackboard announced deprecation of our SOAP Web Services with this article Blackboard SOAP Web Services Deprecation
Now, almost two years later in our Learn SaaS Relase Notes we've written "As of December 31, 2020, Learn SOAP Web Services are no longer supported, as they have reached the end of life per our deprecation policy." What does this mean for you as a develoepr?
The most common concern is "Will my SOAP code continue to work in an earlier version of Learn?" or some variation. Here's a recent example: "Will this be for all versions, or will SOAP API still be available on version 3800?"
The answer is that client's self and manged-hosted systems that are on older versions of Learn will not be impacted. If your client is runnign 3800.0.3 and upgrades to the most recent Cumulative Update, the SOAP Webservices should continue to work for them.
For self and managed-hosted clients that are on 3900.0.0 and are now upgrading using the same build numbers as in SaaS, SOAP will not be supported in any release post Dec 31, 2020.
Another common quesiton is from those using the Learn LIS 2.0 SIS integration, which is SOAP based. No, we are keeping the LIS 2.0 SIS integration in the product at this time. It will not be affected.
If you have additional questions, drop a line to developers@anthology.com and we'll update this blog post with the answer.
Happy 2021!
Most people like cookies. Internet browsers used to like cookies, but a lot has changed in the last few years.
We are seeing a lot of applications stop working in some browsers because cookies are not being shared, and this post hopes to help explain why that is happening and what can be done about it.
A web application may set a cookie to track a user’s session. This is very common, however if your web application is going to be hosted in an iframe, then there’s a good chance your cookie won’t be sent back to you. This is because browsers are clamping down on sending “3rd-party” cookies back to applications hosted in an iframe. Note that a 3rd party is a site that is hosted on a domain different than the 1st party, or your web application. The reason is because these cookies can be used for tracking your internet and browsing activity. Safari has disallowed this for years as a user privacy measure.
Another case where cookies aren’t being sent back is during a form POST back to your application. If you set a cookie, then launch to a 3rd party application, if that application does a form POST back to you, the browser will likely not send your cookie back because it is trying to help prevent cross-site request forgery attacks.
Rather than detail all the scenarios and work arounds here I link to two web pages that are immensely helpful in explaining the situation and some possible workarounds.
The TL;DR is if you must set a cookie in your web application, be careful how you configure that cookie’s properties, and understand that at least in Safari, your cookies may not get passed back to you. The other browser makers are going to get as restrictive as Safari soon.
New in SaaS and the forthcoming 3900 release* an @X@user.student_id@X@ template variable!.
-markk
Read this article . Download Oct 2020 - Changes that will impact Learn Integrations.docx to find out how to get early access for testing.
-Mark Kauffman
Today we launched two new sections of developer documentation - Ally as a Service (AaaS) and the [Learn Ultra Extension Framework](/rest-apis/learn (UEF). These new APIs give you access to integration points and functionality that allows you to bring the power of Blackboard into your applications, and ultimately, your user's experience.
Ally as a Service is a standalone, separately licensed API to apply specific components of Ally's approach to content within your application. In its initial form, you are able to upload files, process them through Ally's accessibility checklist, and retrieve data that tells you what can be improved. This is only the tip of the iceberg, so make sure you continue to monitor this amazing capability for enhancements moving forward. For more information, including a conversation about pricing, reach out to your Account Executive.
The Ultra Extension Framework Premium APIs allow an integration to subscribe to events happening real-time in the Ultra UI, and respond to those events by interacting directly with the UI to do things like open panels, display modals, show messages and notifications, and augment the help system in Learn. Partners will need to be at a bronze level or higher to access these Premium APIs. See the partnership team for more information. If you are not a partner, check out how to become a partner. Licensed clients need only request access. Access is granted to your group in the developer portal, much like rate limits. Just open a case on Behind the Blackboard to get started!
As always, let us know if you have any questions!
Happy Coding!
New!! Visit the REST Tutorials and UEF Tutorials pages for our tutorials on these topics!!
Cheers! -markk
Be sure to revisit the Developing an LTI Advantage Solution page for the latest and greatest tutorial from DevCon 2020!
Cheers! -markk
DevCon 2020 is in the books, and what an amazing conference it was. This blog will start a weekly series in which everything Thursday, we will talk about DevCon from a content perspective. To begin this series, I want to set some context about the scope of this conference, so you, the reader, will have a baseline to base your opinions from.
So let's start with some basic figures:
If we really look at this, we can come up with some interesting insights.
If we base our calculations on unique attendees to live sessions, we can see that the average attendee spent almost 6 hours actively engaged in sessions. We had 71 hours worth of sessions spread out over three separate time zones -- Monday - Friday 8am-10am EDT, Monday - Friday 1pm-3pm EDT and on five days, 3pm to 4pm, and Monday-Thursday 8pm-10pm EDT -- so the average attendee joining 6 sessions is pretty amazing.
We also issued 6.6 badges per active attendee programmatically through Badgr. These badges included attending at least 75% of a collab session associated with a session, pathways, which awarded badges based on predetermined groups of session badges, interaction with Ally, and earning points and promotions in the leaderboard.
Speaking of insights, let's take a look at a few that show how users interacted with the content provided:
Numbers and charts are cool, but what really matters from a DevCon perspective, is the experience of the attendees. Here are a few quotes that I think sum up the DevCon 2020 experience more that any statistic or chart can:
“SUPER big high-five / cheers / shout-out and ALL the other superlatives out to @Scott Hurrey and all that helped make this 2020 DevCon !!!! have greatly enjoyed it in this time of Social Distancing”
“Thanks @shurrey Scott for an awesome experience.. and thank you to all the presenters as well as participants. Look forward to continue networking and finding better solutions for students and faculty.”
“A big thank you to @shurrey and colleagues from @Blackboard for making the 2020 #DevCon a really special online experience. Spreading the event out over a fortnight gave participants a chance to practice and play, not just listen. Fun in dark times.”
To summarize, DevCon 2020 was a unique experience, and one that gave me a little bit of normalcy. Of course I would rather see everyone in person, but since I can't, I was extremely happy we could have a virtual get-together.
Happy Coding! -scott
DevCon 2020 kicked off in full force this week with clients, partners and Blackboarders around the world coming together in Learn Ultra to network, share knowledge, and dig deeper into Blackboard tech.
We’ve had a record number of people at DevCon with 2,273 attendees logging in from 973 institutions and 43 countries throughout the week. We also had some amazing content, delivered all over the world.
Our most-attended session was 'Collaborate Best Practices' presented by Amy Eyre from the University of York and Helga Gunnarsdottir from the University of the West of England (UWE), co-chairs of the EMEA Mobile and Collaborate User Group, affectionately known as MoCo.
Other highlights include the 'May the Data be with you' series. I definitly miss seeing everyone in person, so the lively interaction in these sessions led by a talented group of System Administrators was definitely the next best thing. Big thanks to Casey Eubank from WSU Tech, Chris Bray from Arkansas, Heather Crites from Columbia State Community College, Dan Gioia from St. Louis Community College, Bradley Lawton from Louisville, and Mark Reynolds from University of Illinois at Urbana-Champaign.
There were also a number of other sessions that were well-attended and extremely interesting, including:
I wish I could list highlights of all of the sessions, but in the spirit of brevity, let me just say thank you. Thank you to all of our presenters for taking the time out of your busy schedule -- sometimes crazy early, crazy late, or both -- to share your knowledge with the rest of our community. There is no better way to support and learn from each other than open communication. I look forward to building on this virtual DevCon to continue that global communication.
Next week, we’ll continue running sessions three times each day to accommodate all time zones and schedules. Here are some sessions you won’t want to miss:
And don’t forget about Hackboard: Data. This weeklong event will allow attendees to build meaningful insights against the wealth of information Blackboard Data puts at your fingertips. We’ll kick off Monday and finish on Friday, with two Q&A sessions in between. So add the Hackboard: Data session to your schedule and join us for the kickoff on Monday!
As I write this, it looks like Mark Reynolds is atop the leaderboard, with Bradley Lawton and Eric Silva fast on his heels. And I would be remiss if I didn't mention our badging with Badgr. So far (not including Friday), we have awarded 480 badges, including:
Hoping to see all who attended and more back on Monday as we get ready for another week of great content from our clients (and us, too).
Now you know, I can't let the chance to write some code poetry pass by:
DevCon – one week down.
Full of tips, tricks, chits and chats.
Earn those badges yet?