Tag Archives: Developer

What is “table stakes” for API functionality?

What is “table stakes” for product development these days? Do you believe that we should be following an “API first” development strategy?

I recently (well it was a year or so ago) came across some cool SAP SuccessFactors functionality which allows for a person to be put temporarily into another position, returning to their substantive position after a fixed period. Many of you will know this as “Higher Duties” or “Temporary Assignment” functionality. The problem I found (more recently) was that whilst most of the information about the temporary assignment was available via API, one key piece of information (very important information), the end date of the assignment, was NOT available via the standard SAP SuccessFactors OData API. ☹

Surprisingly, and luckily, the information is available via the old SFAPI (a SOAP based API, and we all know how much developers love SOAP!) So I can work around this for the moment.

This said, to my thoughts, new(ish) functionality, like HD/TA for SAP SuccessFactors should always allow for the data that can be seen in the frontend application to be available via the OData API. That should be “table stakes”. A modern HRIS must be supported by a secure, open, documented and complete API. I often ask potential customers during sales presentations, to compare SAP SuccessFactors with the other products they are considering to Google “name of HRIS solution” + “API” and see what is returned, whether they need to sign in to see it, are there supporting document, examples, etc. SAP SuccessFactors pretty much always wins this game (mainly because Microsoft and Google don’t have competing products in the space, because they use SAP SuccessFactors.)

SAP has come a long way in making its products somewhat developer friendly, so it really irks me when I’m told “We do not have this on our roadmap at this point in time, please raise an influence request”. So I did – https://influence.sap.com/sap/ino/#/idea/308298

If you’re an SAP customer and you manage to read this far into this post, please do me a solid and log in to vote for my influence request! Thank you! Whilst you’re there, have a look around there are loads of requests that would make so much sense to implement, vote for them too.

Customer voice is so important – and this “influence.sap.com” space is one area where we as customers actually get a little bit of a say!

Link

Screenshot from https://www.workday.com/en-us/applications/workday-cloud-platform.html

So Jarret Pazahanick, posted me a link to the details of the more detailed announcement of the Workday PaaS (it having been earlier hinted at https://diginomica.com/2017/07/11/workday-finally-pops-paas/  http://blogs.workday.com/open-up-workday-cloud-platform/ a couple of months back.

He wondered at my thoughts. Well, here they are.

Firstly, I’m really glad Workday are saying they are releasing a PaaS, it justifies all the work that I have been doing in this space. Having a PaaS to support your SaaS based HR solutions is now pretty much de-facto table stakes.

On the downside, Workday didn’t actually announce a PaaS at all. They have suggested that developers use other PaaS to deploy and run the applications and then integrate the applications via a newly released suite of APIs.

I think the most telling thing about Workday’s PaaS is the disclaimer on their website. It isn’t publicly available and they may not deliver it at all.

Whilst the claim on the website is “The Workday Cloud Platform is built on the principle of openness” it’s not possible to access the details of the developer website without requesting a user id, so I’m not even sure of the scope of the APIs that they are releasing.

In fairness this is a similar situation to SuccessFactors about 5 to 6 years ago. Then even high level details of their APIs were a guarded secret. I remember one of my very first presentations about developing applications on what was then the SAP Netweaver Cloud, integrating to SuccessFactors Performance and Goals. It was painful to figure out how to do it. Now there are Open SAP MOOCs that step you through easy platform enabled steps.

https://open.sap.com/courses/cp3sf

Screenshot from Open SAP open.sap.com

I’m pretty sure that Workday will move to a more open model, the industry demands it, but until they work out a way to deliver an actual platform that their customers can run apps on, not just the services to support the apps, then I think we should really call them to task for calling something that is NOT a PaaS, a PaaS.

It’s nice that Workday feel they need to have a PaaS, but what I’ve seen doesn’t count as that, at least not in my understanding of the term.

 

On ABAP in the Cloud

ABAP in the cloud

Michael Koch kicked it all off with a tweet,

to which of course I had to reply:

then I was prodded:

and prodded:

and then James beat me to the blog:

and if you haven’t read James’ post, please do, it is excellent.

So whilst I’m waiting to hear how much it’s going to cost me to fix my car of which the engine has decided to stop working whilst on the way to work today, I thought that rather than drinking a bottle of Pinot Gris and attempting to forget about the shitty waste of a day I’ve had, I’d do something useful, productive (this post), and drink beetroot, apple, ginger and celery juice instead.

So here are thoughts upon which I will rant.

  • ABAP is a proprietary language which make its code costly to support.
  • Building for cloud is far more than just supporting cloud systems.
  • If you love ABAP to the exclusion of everything else that’s your bed, you lay in it. I like beetroot juice, I am so going to have pink pee later.
  • Java is the boring enterprise language of choice.
  • A PaaS really should be language agnostic, if not it’s a pretty crappy PaaS.
  • Why on earth have we ended up here? Who is paying for this?
  • Evolve or die.

These are all going to get intermixed in this rant, but I will still try to address them one by one.

Firstly, on the joys of ABAPers. I have discussed and even written about this, and it may just be the particular markets where I play, but it’s damn hard to find a good and excited ABAPer. People don’t learn the language unless they want to work on SAP products. Imagine how quickly that strips out the fun people. But where people have got good ABAP skills, they tend to have far more than that, also great business process understanding (Robbo has recently written about this https://blogs.sap.com/2017/10/02/abap-in-sap-cloud-platform-why/ ) Have a read, especially if you fall into the ABAP diehards camp, it will make you feel much happier than this blog post will.

But because the good ABAP folk have such great depth of business process understanding, they command a reasonable rate – and why not having a BA and a coder in one is a bit of a win is it not? So they are expensive. One hopes because they deliver better, but I find this is not true. They just cost more. But you have to have them to support the huge monolith that is your SAP ERP system. So embedded in companies around the world are these folk who can code ABAP, understand their systems and are if not well paid, expensive to have hanging around.

And you won’t find someone off the street who has just learnt ABAP who is useful, because the skill in ABAP isn’t in the language, it’s in understanding the existing library of  standard code and frameworks that you can use to get things done.

FFS the language still doesn’t have the concept of a Boolean!

The requirement for ABAP support is one of the reasons that SAP costs a decent amount to run. In the future as we move to S/4HANA public cloud (and we will, slowly but inevitably) cost saving will be essential. ABAP costs, so get rid of it in the equation. Out-source your custom development, even better, purchase it as SaaS from someone else, are you a custom software development house? No – they why do you try to build your own software? Concentrate on dishwasher powder, chocolate bars, beer or whatever it is you have as your core.

If we start building cloud extensions in ABAP we are locking down the list of people who could support them. This will cost us extra. Having worked with SaaS for the last few years, I can clearly state, cost of delivery is far more important now than it ever was on-prem. The expectations of customers are different. They will not pay the same amount to build an extension as they paid for the SaaS solution it enhances. ABAP ain’t cheap, and neither are ABAPers.

I don’t think ABAP and it’s whole lifecycle management is really well designed to build cloud apps. James mentioned some great points in his blog around dependency management, and how ABAP doesn’t support non-linear and project based development (hopefully ABAPGit will help here, the official voice of support from SAP is very encouraging.) But having spent the last 5 years build cloud apps that integrate to SAP systems, I have been so impressed by the huge amount of standard tooling and functionality that is available for projects outside of SAP. Like have you used Maven? It’s fricking awesome! To consider even thinking about managing the huge number of libraries that I use in most of my builds to do without this tooling would be unthinkable. Since James was probably more detailed and eloquent on this point I will stop there. But really, even if SAP support ABAPGit there is a hell of a long way to go to even think of being put into an imaginary cloud development language magic quadrant chart, let alone featuring anywhere but bottom left.

#ABAPisntDead. No of course it isn’t, there will be legacy on prem apps that will run and people will make businesses out of it, like those Rimini Street folk. But if you can’t see anything out there other than ABAP, my goodness you are short sighted. Any good programmer out there should be able to code in js (server side or browser), and should have a grasp of at least 2 other languages. If you can only deal with one, you’re not a programmer, you’re a liability for the people you work with. Having multiple skills is important, and it’s also important to know when to use them. Enlighten yourselves people, there is a whole world full of cool shite out there, go and have a look. If my post infuriates you because you believe that ABAP is the best thing ever, awesome, both for you and for me, because you have passion, go and use it, and me because it means I actually got some people who don’t agree with me to read this.

Java is boring, and safe, and commodity. And that is exactly what businesses love. You want something that is reliable, has been proven, does the job. Moreover, you want bucket loads of libraries that other people have built and tested that can do the things you want to do. Whilst I built an implementation of TFA that was compatible with Google’s TFA Authenticator app in ABAP, it was a pain in the arse, and hasn’t been updated since I wrote it and then worried about releasing it as open source because you weren’t allowed to do that with ABAP. There’s a standard lib for Java. Standard boring languages are the bedrock of good enterprise builds. I do like to play with server side js, (aka Node) but i’m still a sucker for strongly typed languages.

But if you don’t like Java, then awesome, choose something else. Indeed it should not matter what you choose, because any PaaS you build on should be language agnostic when it comes to providing services to you to consume. If you’re not consuming any services from your PaaS then you missed the memo about cloud development, please go back to your application server. A PaaS offers micro-services that should be able to be consumed by any application running on that platform. This inherently makes those services consumable in a fashion that is hard to use for ABAP and pretty standard for every other language. I’m sure that SAP could wrap their services into a consumable layer that would be easier to use in the Cloud based ABAP. But this then means we start losing one of the best bits of the PaaS, that it shouldn’t favour any runtime. We’ll see how this story plays out…

Which kinda segues into my next worry/rant/observation. How did we get here that a language that really isn’t suited to cloud extension ends up as an officially supported run time in SAP’s CF PaaS? This goes back to my original tweet.

I believe that it is clearly SAP’s strategy to move to the largest part of their revenue coming from public cloud based SaaS solutions (including ERP). Btw, I think this is a sound strategic vision, because if they don’t pivot to get there, someone else will take that space. The on-prem model will not make as much money in the future, todays small companies are tomorrows giants, and with SaaS solutions they don’t need to migrate/upscale, they will keep the solution they buy today. SAP needs to be in that space, and they need credibility that comes from large customers being there too.

To this end I envisage SAP have been discussing moving some very influential customers to the public cloud. Those customer, I would guess, have responded that they don’t want to loose their current people or custom build investments.

The obvious solution from SAP is to put together an ABAP cloud runtime. I cannot be cheap to do this though. The effort to make ABAP into a secure and lightweight containerizable solution will not be something that a team will do in a week or two. There must be some sound and solid business reasons to do this. For all the reasons I have previously mentioned I believe that if companies want to extend SAP SaaS solutions, they should think about using other languages, not ABAP. But I fear this is not about making a better solution, it is about making a marketable one. If customers believe that they can extend the value of their existing investments and also benefit from moving to SaaS based solution, that is a great sales pitch. It’s having your cake and eating it.

This vision (even if it doesn’t work out to be the reality) of a simple gateway to moving to SaaS ERP is what I believe we are now being sold. This isn’t a story for developers, this is a story for the high level execs that sign the S/4HANA subscriptions.

I hope that a cloud based ABAP will be the gateway that enables some organisations to get off the on-premise mode and head to the cloud. What I fully expect is that once they are there, they will realise that there are better and more supportable ways to extend. That would be great. In the meantime I fear that we start bringing non-cloudy ways of working into the cloud landscape, this will likely cause failed/cost overrun projects. We run the risk of preferring Cloud ABAP as a way to interact with S/4HANA cloud, that would be disastrous.

It has been suggested that Cloud ABAP will potentially be the solution that encourages adoption of the SAP Cloud Platform. I just hope it isn’t the solution that kills it. I would much rather the money being spent of putting ABAP into the cloud is used to handle some of the other issues I see with SAP CP, but clearly there is a view that it will be a return on investment.

Then again, if you’re not trying new stuff and making mistakes, you’re not learning. If you’re not learning, you’re falling behind. So here’s to making mistakes and learning! To steal the excellent closing lines from James’ post:

So buckle up because there’s no turning back at this point. It’s either evolve or die.

I look forward to a lively debate on this topic.

(James Wood – https://blogs.sap.com/2017/10/04/abap-in-the-cloud-is-this-a-good-thing/)

James, I couldn’t say it better mate. Although I would refer to the platform as SAP CP 😉

I think SAP Cloud Platform is and will be a key part of the story of SAP’s  and customers’ evolution to the cloud. If it takes putting an “runs ABAP” badge on it, to get people to see how useful it is, I’ll deal with it. But for sure, it would not be my recommendation to any organisation that it would be best practice. I’ll keep an open mind, perhaps it will be one day, if so I’ll adapt and evolve – because that’s what you should do.

As always, my own thoughts, not my company’s,  please feel free to jump onto SCN and reply to James’ post. I’ll probably read those comments as well as whatever gets posted on twitter.

 

Herding cats, or managing GitHub issues – Waffle and HuBoard considered

Today I needed to decide on a tool to use to manage GitHub issues. I’ve got so many of these now-a-days that it has become quite hard to decide which one to work on and also to communicate to others which ones I am working on.

So I turned to some of the simple Kanban board visualisations of GitHub issue tools that I’ve seen. There may well have been others (I’m pretty sure that it’s possible to get Trello to work with GitHub) but I wanted something that was simple.

I ended up comparing waffle.io and huboard.com .

HuBoard

I found that HuBoard had in many areas some cool functionality that could well be something I wanted. In particular it has the ability to mark a task/issue as “ready for next stage” and “blocked”. Blocked issues are particularly important to me – so having this clearly visible is important. Additionally HuBoard claims to have existing integration into Slack – that would be pretty cool, but given I already have GitHub integration into Slack, I’m not sure it’s needed. Would have been nice if the web-site had shown what that integration actually was, as that is something that could really decide me one way or other.

HuBoard has a nicely minimalistic view – more inline with newer design patterns like Android material design, SAP Fiori. Labels on issues are small colour coded lines that appear when you hover over them.

huboard design

It’s quite neat and tidy. It also has a cool “fade away” filter option that just fades out un-selected items rather than removing them (two clicks removes them). However, clicking the same button multiple times to get different affects, I’m not sure that’s really a great idea. I’ve definitely been slapped over the wrist for bad (and not very accessible) UX when I’ve done similar things in the past. But technically and from a usefulness stake (if you understand what you’re doing) that’s a pretty cool feature.

However, I there were some concerns – when I loaded the HuBoard site on my phone it was good to see that it adapted responsively to the space available and listed the items rather than displaying a grid (well, I’m still debating if that was good, but at least it was responsive.) However, when I then clicked on a issue:

mobile huboard issue small

Yuck! that’s not usable.

Edit: NB see note following stuff documented in following section about privacy has been changed.

I then looked at the site to understand what the privacy policy was:

privacy policy from HuBoard missing

The only info on the site was “This Application collects some Personal Data from its Users”.

I’m pretty sure this is because of HuBoard not paying someone for their generated policy:

huboard policy issue

 

However, I tweeted at HuBoard:

And as at time of writing this post, haven’t had a reply. To me, if I’m going to trust a cloud service, I need to be able to understand what it will and won’t do with my data. A non-working privacy policy page on the main site is a BIG #fail. Then not to respond to someone @ mentioning your twitter handle is a mark of the kind of service that I might expect if I was a customer. Not great.

Edit: so none other than the founder of HuBoard reached out to me. Privacy policy is fixed. It looks pretty good too, most of it is in plain English not legalese. Guess timezones for USA meant they were sleeping. The founder reaching out, that’s pretty good customer service. These guys will hopefully do some great things!

 

Waffle

I looked at Waffle.io. Now bizarrely the thing that most scares me about that product is its price – $0. I’ve learnt, if I’m not paying $ for something, then I am the product. I’m not sure if Waffle.io is still in beta/investor funding and is happy running without making any money but perhaps just piling up the company valuation? This whole SaaS valuation model sometime confuses the crap out of me. When you consider that companies the size Workday have profit margins of -24% (I mean WTF ?) It’s quite conceivable that charging money right now doesn’t boost the value of the company as much as having more subscribed users. Still paying nothing for something just makes me want to look for the catch. But I couldn’t really find a catch (I imagine it won’t be free forever and that payment will be required soon, but if it’s in same sort of price point as HuBoard then this shouldn’t be an issue $24 a month to be productive is not that bad!)

Waffle has some feature that I thought were pretty good, but specifically I liked the “size” attribute for an issue. By using this I can ensure that for each stage of the Kanban there aren’t too many issues being dealt with. So it can be fine to have quite a few small issues, but having the same number of large issues could cause a problem.

waffle

 

at the top of each column was a counter showing the number of issues and the total size. Next to my lovely picture was a number showing what I thought the size of this issue was.

This functionality I like, it will help manage all the issues and ensure we’re not going crazy pushing so much to into testing without actually testing it.

It was also nice in Waffle to be able to see the number of comments an issue has – it’s often worth drilling into those issue that have a lot of comments, even if it’s not yet my issue.

However, compared to HuBoard the amount of information shown can result in a quite busy screen – for example from Waffle’s own GitHub repo…

waffle2

 

Personally, I didn’t mind the “noise” but others I spoke to thought perhaps the minimal style of HuBoard better. Since I often have so many labels that colour alone is going to be an issue, I think I prefer this layout.

In contrast to HuBoard the mobile interface is not at all responsive, you see the same site but just zoomed out so you can’t read anything. That said, pinch zooming and scrolling around on the phone isn’t hard, and it does give you a better perspective of how the lanes compare. I’m pretty sure that there is probably a better responsive layout that could be adopted. But compared to the rendering mess that happened in HuBoard when accessing from mobile, it was much easier to use the Waffle site.

Conclusion

You can probably see where I’m heading! I decided to go with Waffle for the moment, but I’ll keep an eye out for HuBoard. As with all these SaaS apps, iteration is the name of the game, and I’m sure that feature parity won’t be far off. Neither tool has an Android mobile app, but neither tool is very usable on a phone – so perhaps when one of them makes that leap it will differentiate itself. We shall see.

After I’ve been using Waffle for a while, I’ll perhaps write another post about “real life” experience.

Cheers!

 

 

iOS – not quite the Enterprise developers’ best choice

I was recently at a conference where there was a big cheer from the audience when the vendor announced that they were moving away from a model of updating all the customer’s development/test and production systems 4 times a year, to a model of still doing quarterly updates, but updating the dev/test environment one month earlier. The crowd cheered. Wow! (The conference was SuccessConnect, the product SuccessFactors and the vendor SAP, but that is irrelevant for this particular post).

So why on earth would people want to get their software updated later? And why would such a change cause them to cheer? It’s quite simple really! Risk reduction.

risk reducer

 

Reducing Risk

To quote Donald Rumsfeld “there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know”. Whilst it’s blinking difficult to deal with the third category of “unknown, unknowns”, it’s much easier to deal with the known unknowns. In our case of software upgrades, we know that there are likely to be changes, but we aren’t sure exactly what. So having a early release in a system that isn’t critical for the running of our business, means we have the possibility to make those known unknowns into known knowns and deal with them. (hmm perhaps I shouldn’t have quoted Donald, this is getting a bit confusing! – but hopefully you get the point!)

Basically what was being offered was a risk mitigation strategy, and the enterprise just LOOOOOOVES that.

Back to Mobile apps

OK, so what’s this got to do with mobile applications? We’ll basically for mobile applications in the enterprise space we should be able to offer the same thing. I’m not talking here about applications that companies develop internally and deploy to all their staff, but applications found in application marketplaces (app stores if you will) that are used by enterprises.

Say there is this great app out there that allows you to track the driving speed and location of all your delivery truck drivers. It’s great because the same functionality just a few years ago cost thousands of dollars per truck and had to be downloaded manually each night. Now, you have it instantly and at a subscription cost of $20 per user per year, with awesome real-time reporting and everything! Great! But the reason it is so cheap is the developer is selling this software in a SaaS model. They have a multi-tenant architecture and when they make an update they update all customers at once. Now what happens if they push out an “improvement” in the user interface of the solution? Well 90% of your users will probably adjust, but 10% (or more) are suddenly going to be referring back to that print-out of the training material that you sent them getting very confused, phoning the help desk and generally finding an excuse for not doing work. Bad!

But had you known that a change was coming, what could you have done? Well, you could have updated the training material, sent comms explaining the wonderful new feature, etc.

So how could you have know this change was coming? Well the company that you’re subscribing to could have sent you some details about the change. But what if they thought that the change was so insignificant it didn’t need any comms? And  what if it’s just the particular way that your workforce use the app that means that it might need explaining? Then you are going to need another plan.

Another plan

chrome beta

In the Android application marketplace (Google Play) there is allowed the concept of a Beta version of application. Many popular applications (for example Chrome and Firefox) have beta versions of their software that showcase and test out new versions of UI and functionality.

This allows companies to test out new versions of software before their major install base start using it. And because the software is flagged BETA people know that there might be things different. It is a risk reduction strategy for not only the consumers of the software but also the developers. Win-Win!

Apple however in their app store submission guidelines: https://developer.apple.com/app-store/review/guidelines/#functionality

2.9  Apps that are “demo”, “trial”, or “test” versions will be rejected. Beta Apps may only be submitted through TestFlight and must follow the TestFlight guidelines

and from the TestFlight guidelines: https://developer.apple.com/app-store/Testflight/

External Testers (Coming Soon)

Once you’re ready, you can invite up to 1,000 users who are not part of your development organization to beta test an app that you intend for public release on the App Store.

So instead of making a publicly available Beta version they are going to restrict to a maximum of 1000 Beta testers. Not so good for that SaaS developer with over 1000 customers is it? And even then – that functionality isn’t even release to the market yet! The whole TestFlight thing was only announced a few days ago!

In summary

So back to my title – if you’re a SaaS developer and you want to help your customers by reducing your risk and theirs in the mobile application deployment space, build for Android, not Apple. If you care about enterprise, then be aware that risk mitigation is a big thing. The reality is that as an enterprise developer we need to deliver for both Android and Apple devices, but one of them is clearly more enterprise friendly in one particular respect.

Would be great for Apple to take this on-board and offer a unrestricted “TestFlight” program for enterprise software developers… We can cross our fingers and hope!

Continuous Integration vs Phased Deployment in a SaaS world

I was very interested to read some links that Naomi Bloom posted about how Workday have moved to a continuous integration deployment model rather than a phased release.

As  developer, I love the idea of continuous integration, having a set of tests that can automatically check whether the code I have built will cause an issue in production and then allow me to move it up to prod immediately. It fits with TDD and all the other cool things I want to do. Awesome!

If I were writing code in the internal development teams of Workday or SuccessFactors, I’d want the software to be CI.

However! As a developer of extensions to one of those platforms, I couldn’t think of a worse option! If you look at the “disadvantages” section in the linked Wikipedia article on CI, you’ll notice that one very important thing is to have lots of good automatic test scripts. The problem is, a vendor can only possibly run their own test scripts, they can’t run mine. (Perhaps they could run mine if such an API was built, but could they justify not deploying to prod because a little used partner extension failed a script?) So what if some change that the vendor does breaks a behaviour in my code? Well, that’s bad for me. I’d better hurry up and fix it, because all my customers are now with broken code, and the first I found out about it – when it broke. And likely I’m not going to find out until I have one of my customers complain – unless I have proactively set my test scripts to run every hour and send me a message when something breaks, in which case I’d better be ready to do emergency support 24/7. Yeah, just what I want. NOT!

This would be a huge burden on a extension provider, you wouldn’t have a stable platform to build on.

With SuccessFactors being on a phased release rather than continuously integrated to production, it is much easier for me to join in with the testing of my solution before it hits the market. I know that my customers aren’t going to get a nasty shock because something suddenly breaks/changes behaviour, because I have a window to test that before it impacts them. I also know when that window is going to be, so I can plan around it and allocate my resources. Whilst the solution might be wonderfully cloudy and elastic, my skilled pool of extension developers is definitely less cloudy and more finite and fixed.

Now it might be possible to allow partners to have an early access box, and perhaps delay CI deploys to production by a week or so to allow partners to test their code. But that is one hell of an effort that you’re demanding of your partners to do that. And as one of those potential partners, I can say I’d be thinking very long and hard about the risk you as the vendor are putting me at, and probably would decide not to go there.

I think, that in a world where purchasing 3rd party add-ons for your cloud platform will become the norm (allow me my dreams please). And where the power of the platform is driven by these add-ons/apps, having a phased release makes sense. How cool would an iPhone be without any apps from the AppStore, how good would an S5 be without apps from Google Play? They are both great devices, but they are awesome when enhanced by external developer partners. These mobile solutions have phased releases. It’s not because they couldn’t have constant updates, the tech is easily there for that to happen, but because in order to sustain the applications/application developers that make them so cool they need to provide a stable platform.

I’m really glad that SuccessFactors provides a stable environment for me to build on, as I am convinced that HCM SaaS has a huge potential to be enhanced and extended to the better use and consumption of businesses. It’s a real strength of the solution, and I am very happy to be play a part this story, and that SAP and SuccessFactors are carefully considering the needs of the development partner in this scenario.

All that said, it would be cool to be developing in a continuous integration solution, but just not for the partners building on your solution.

Scaling or cropping profile images into circles when the source isn’t a square

WARNING CODE AHEAD

<geek>

It took me probably too long to figure out how to do this so I thought I’d share.

circles

To do this in a way that most browsers support wasn’t so obvious (to me).

in the end I did it by (approximately):

HTML

<div class="profile-image" style="background-image:url('profile-img1.jpg')">
 <img src="profile-img1.jpg">
</div>

CSS:

div.profile-image {
 width: 47px;
 height: 47px;
 background-repeat: no-repeat;
 background-position: center center;
 background-size: cover;
 overflow: hidden;
 border-radius: 23.5px;
 -webkit-border-radius: 23.5px;
 -moz-border-radius: 23.5px;
 box-shadow: 0 0 4px rgba(0, 0, 0, .8);
 -webkit-box-shadow: 0 0 4px rgba(0, 0, 0, .8);
 -moz-box-shadow: 0 0 4px rgba(0, 0, 0, .8);
 border-radius: 23.5px;
}
div.profile-image img {
min-height: 100%;
min-width: 100%;
 /* IE 8 */
-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)";
 /* IE 5-7 */
 filter: alpha(opacity = 0);
 /* modern browsers */
 opacity: 0;
}

The image tag is in there so it’s still possible for the user to interact with the image, i.e. save it if they want, but it is made see through.

So the user “sees” the background image which is positioned such that it covers the div, so all of circle will have content, and the middle bit of image will be shown. The circle is made by making the border radius half the width of the div.

The important bits were the “background-size: cover;” and the “background-position:center center;”

Obvious when you know how.

</geek> (as if!)

 

credits to : http://stackoverflow.com/questions/11552380/how-to-automatically-crop-and-center-an-image for the inspiration!

#SAPPHIRENOW what it meant to a developer

I make no secret that I love developing. My favourite job title is “Chief HR Geek”, I adopt others as the need arises, but as a real in the dirt developer, content is always more important to me than flashy styling.

That’s why I was one of the only attendees at SAPPHIRENow 2014 wearing shorts. It’s fricking HOT in Orlando in June, wearing a suit?! Are you kidding me?

But it’s worth noting that to most businesses in the first instance, flashy styling is worth more than content! BUT – flashy styling with content, that’s awesome.

Fiori

With the announcement of Fiori being available as part of standard maintenance (yar boo sucks to those companies who’ve decided to skip SAP maintenance and have a third party do it) there comes the possibility of a double whammy of flashy styling and good underlying content.

The demo of a CFO drilling down in real-time to underperforming or problematic areas of the business and analysing why was compelling. I think Robbo has written about this as the killer app for HANA. I think he might be right.

But the key thing for a developer here, was the front end that this was achieved with, wasn’t a Business Objects add-on, wasn’t some WDA functionality. It was SAPUI5 over an OData layer exposed by Gateway.

If companies are going to be able to adopt these applications – and more and more of them are coming – there is going to be a clear need to support them.

Using tooling to build UI5 apps using ABAP won’t cut it

Whilst there are some amazing frameworks out there to help migrate stuck-in-the-mud ABAP developers across to building UI5 app, this does not help when there is a need to extend a standard Fiori app. Developers will need to learn JavaScript (or more properly ECMAScript, but that’s just me being pedantic.) If you can’t code JavaScript and refuse to learn, start calculating your redundancy payout because that’s what you’re going to be worth to your company. Alternatively, brush up on your SQL skills – and you can start writing some of the pushdown code for HANA. Either way, ABAP is going to be complementary to either DB manipulation or front-end display, but not a stand-alone skill set.

Fiori extension points

Did you know that many (not all!) Fiori apps have built-in extension points? You can use these to substantially alter the behaviour and appearance of the app. But to do so, there is something you should know – guess what? JavaScript!  Whilst the RDE (fingers cross for R to start meaning Rapid in near future) allows for some pretty amazing WYSIWYG modification to apps, the likelihood is that some form of developer intervention will be required. At the very least someone is going to have to figure out if the business requirement can/can’t be met using this simple customisation. And what skill set is going to be needed to figure out what those extensions can/can’t do? Yep you guessed it, JavaScript.

In Summary

For once I’m going to keep to a simple post without the detail that me as a developer I love so much. Because I want to emphasis this message.the future is fiori

I’m eventually learning to understand, unless you have flashy styling (Fiori), it doesn’t matter how good your content is (HANA) you can’t sell it. Combine the two together, and you have something that will change the marketplace and means developers need to change their game.

Perhaps if I ever attend SAPPHIRENow again, I’ll compromise and wear my jeans.