Monday morning thoughts: debugging approach and Greasemonkey revival
In the inaugural episode of Simon Kemp and Jakob Marius Kjær ‘s new Community Podcast we touched on how interesting it can be to find out about other people’s programming setups, even down to the actual screens and keyboards they use. I enjoy learning about how others work, what tools they use, what thinking or approaches they take in debugging, and yes – even what screens they use and how happy they are with them.
I’m sure I’m not alone in this regard; moreover, I know there’s a wealth of untapped, innate knowledge and implicit ability inside all of you that would be great to share. So I thought I’d contribute by giving a little insight into some small approaches and methods I find myself using. Nothing earth shattering, but I think that’s also the point. I personally would love to see from others the equivalent of what I’ve just recorded – I know I’d be the richer for it.
The recording is just over 20 mins, and it’s pretty much unscripted, which is sort of the point – I didn’t want to prepare anything, so you get a real sense of the workflow (lowercase “w”) rather than something polished and less real.
During the recording, I mentioned Greasemonkey, which was a wonderful tool that allowed one to write JavaScript to be automatically executed when certain pages were loaded; that JavaScript could then manipulate the pages to suit your needs. I note that the Greasemonkey spirit is still alive and well in the context of, for example, Chrome Extensions such as Tampermonkey.
I used Greasemonkey back in 2005 to improve the OSS Note experience – you can read about it in this post “Hacking the SAP service portal to make OSS notes better” (unfortunately I lost the screencast but you can get a good idea of what I was building from the post itself).
So I wanted to leave you with two thoughts for this week:
- seeing others’ development and debugging workflow can be of great benefit – getting inside the programming heads of your friends and colleagues and seeing their preferences and approaches can be not only educational but also fun
- the introspective and manipulative power that’s baked into UI5 gives us all sorts of possibilities; the Greasemonkey style approach is by definition (and design) ephemeral, but I think that is one of its charms – nobody is claiming that the “solutions” will work long term, but there are plenty of situations where a quick temporary fix, or a scratched itch, is exactly what’s needed to get the job done.
Do you have some programming or debugging workflow to share? What tools do you use? What does your desktop and working environment look like? Let us know in the comments below.
p.s. For those that are interested, here’s the final version of the JavaScript I put in my bookmarklet:
javascript: (function() {
opl = sap.ui.getCore().byId("application-bpmworkflowmonitor-DisplayInstances-component---InstancesDetailView--ObjectPageLayout")
|| sap.ui.getCore().byId("application-bpmworkflowmonitor-DisplayDefinitions-component---InstancesDetailView--ObjectPageLayout");
opl.insertSection(opl.removeSection(3), 1);
})();
Read more posts in this series here: Monday morning thoughts.
Super Awesome, I never knew if such kind of thing is possible, Greasemonkey Rocks! I normally use Visual Studio Code/Sublime as a code editor, with Vagrant Homestead, WAMP,Python environment and rest F12 always does the trick:). One question which i have is my editor tends to hang a lot, i have tried playing around with disabling plugins, setting variables etc. but sadly of no use. What coding editor normally do you use apart from SAP Web IDE Full Stack of course?
Learning from others is definitely fun. Greasemonkey is definitely i am going to try as most of the time we have to just look at certain part of the page not all, will share my experience while using the same.
Thanks DJ Adams for blogging about it. Keep your #MondayMorningThoughts coming and sharing:)
Cheers Nabheet. Other than SAP Web IDE I use a a couple of editors, depending on circumstance. When in the cloud, I use vim, because I feel most at home on the command line and used to use vim (or vi) when I was doing R/3 Basis administration on all sorts of Unix flavours way back when. I had to get to know vi as it was pretty much guaranteed to be on all systems, so I forced myself to get over the initially steep learning curve:
(image from https://r3dux.org/2013/03/text-editor-learning-curves/)
And the other editor I use is VS Code, which is a nice looking editor with some great plugins, including Quokka, which is worth installing VS Code for.
Hey Nabheet,
You can try Brackets as a code editor. I find it handy while I started learning javascript.
Thanks
Asif.
Love this! I have some new tools to use to debug issues. As I start to use more Javascript - I'm going to need all the help I can get. My main way of programming was to write different messages to my screen. Not real effective as I move forward.
Michelle
Great, thanks Michelle. This is a nice effect of sharing this stuff - helping others discover tools and techniques they might not otherwise have been aware of. And yes, with the Chrome Developer Tools one has a wonderful set of resources to use. Happy hacking!