I like this cheatsheet to give non-technical audiences some insight into a cloud journey for enterprises.
Building an Apple PassKit app has been an interesting endeavor. Internally at SAP we recently built a small Business Card application which allows employees to create a digital business card, and subsequently generate a individual and customized wallet pass, allowing them to quickly retrieve it, without having to find the app, and open it on their device. Having a wallet pass lets users simply double tap the lock button, authenticate and see a collection of their passes.
Awesome video from Apple and our Enterprise Mobility team at SAP.
Over the past few years I have found myself re-implementing and re-writing basic features of server, web, mobile or service components. Registration, Login, Forgot Password, Notifications, Search, Help, FAQ, Contact Us, Maps are just a few I can think of, where half way through the development everything seems familiar and I have a case of deja vu. No doubt I have written or implemented a library or service which performs this specific function.
While developing the Changd app I found myself in one of the deja vu moments while writing the email notification service, and decided to pause development, and fix the root cause. After multiple Github issues to support a variety of notification providers, I came across Apprise, a python library which supports multiple notification provides. Since there was not a Node.js implementation, I decided to use Apprise as inspiration and influence for a Node.js library which I aptly named “Reach”.
May unity be the foundation to explore new grounds.
Every so often you get a product which delights you. A small nugget of wisdom, a token of appreciation or well thought out gesture, showing that the company or person who designed, or built the product, went just one step further than they needed to …
These are the notes/process I used when developing the Node Reach SDK package:
The “Standard” Release Process
Here is my understanding of the steps that are most commonly expected to be run when publishing a new version of an npm package.
- Safety Checks:
- git pull
- git status
- npm ci
- npm test
- npm run build
- npm version
- Or by hand:
- Update version in package.json & package-lock.json
- git commit -am ‘2.0.0’
- git tag v2.0.0
- npm publish
- git push
- git push –tags
This is another blog post of a series around the enterprise mobility IT team at SAP. We are an internal team focused on managing mobile devices, mobile applications, and developing custom apps for SAP’s 110,000 employees. I believe we have some unique stories, software, tools, and insights to help others in the community considering, or currently undertaking, some of the challenges which surround mobility and its adoption in the enterprise. As an SAP champion, I enjoy sharing and promoting my experiences and knowledge with others through the SAP Community, if you enjoy this post, check out some of my past content.
A few weeks ago I gave a presentation on “Why apps matter …” for an annual internal SAP event called SAP Worx. These presentations highlight some of the important internal tools which IT develops to help our employees in their daily lives. While this was internally focused, I felt it could be beneficial to share some of the details and content behind what, we as a team, are focused on from a mobility perspective.