Looking for sessions from Dreamforce 2017 I found a list of sessions in a speadsheet and for fun I threw together a quick app to provider a better overview, allow me to filter the list easily and generate playlists on Youtube for select sessions. The app is written in node.js, is available on Github and is hosted on Heroku at df17playlistgenerator.herokuapp.com. After you authorize the app for Youtube it displays the list of sessions and you can generate playlists.
As a good friend of me always says – YMMV… Use at your own risk.
The other day Salesforce Workbench was having issues. Generally it kept returning errors and SOQL queries took forever and timed out. Now Salesforce Workbech is a LAMP app that runs on Heroku and it turns out it is actually possible to deploy your own instance on Heroku using a simple Heroku Button. To do this simply follow the below steps (you need to have an account but if you don’t simply sign up):
- Go to the project page at https://elements.heroku.com/buttons/jdrishe/salesforce-workbench
- Click the Deploy to Heroku button (use the button on the bottom and not the one on the top right as the one on the top right deploys and older version)
- Log into the deployed app (remember to add your security token after the password but I guess you knew that!!) and you are done!
Now you have your own instance of Salesforce Workbench running on Heroku. So nice. Below is a small video I recorded showing the actual steps and realtime – just over a minute and you have your own instance! Boom!!
Using Salesforce Lightning Design System (SLDS) is a great and easy way to add some super nice styling to your app. It comes with some nice defaults and a responsive grid system like other frameworks lige Bootstrap. Where SLDS really shines is of course if you are already using Salesforce (I assume you’re already on Lightning right?!!?!?) or if you are going to. And again who isn’t. Anyways… Using SLDS makes your apps really look like Salesforce which is nice for Salesforce Lightning Components or for an app using Lightning Out to host Lightning apps in external applications.
I often use SLDS for another use-case which is quickly doing a mockup for a new Lightning Component. Doing it in SLDS can often be way quicker than making by hand from scratch or attempting to draw the component using Powerpoint or other tool.
Previously I’ve been using the download option for SLDS ie. grabbing the package of the website, expanding and copying into my app. Today I tried out the NPM solution as I often use node.js and Express when I need to mock stuff up. Installing SLDS is as easy as doing a “npm install @salesforce-ux/design-system –save” and you’re all set. Mostly. Problem is of course that the assets you need end up in the node_modules directory which is not exposed outside the app. The way I get around it is to add a static-rule to my Express server.js as follows:
const app = express();
app.use('/slds', express.static(__dirname + '/node_modules/@salesforce-ux/design-system/assets'));
Then loading SLDS assets into my app is as easy as:
<link rel="stylesheet" type="text/css" href="/slds/styles/salesforce-lightning-design-system.css" />
This works great if/when you post your app to Heroku as well and has the additional benefit of easy version management using NPM and package.json.
My parents mobile broadband connection in their summer house seemed a little flaky and my father asked me how we could monitor it. Easy I thought. I would simply grab a Raspberry pi and one of the available tools so I googled and found a nice tutorial. Getting it to work was easy enough but after having this run for a few days the results were weird and didn’t match what we saw while there. So what do any self-respecting programmer do? Write his/her own of course… 🙂
So I broke out my language of choice (Java) and wrote a simple servlet I could use using curl. The servlet responds to GET and POST requests and hence allows me to measure download and upload speed. Using curl it was very easy to capture the connection time and the actual time to do the operation. Putting it all together using cron allowed me to run it on schedule and pipe the result to CSV files for later analysis.
Now I needed a place to run the app – the obvious choice was a free dyno on Heroku. To deploy I simply created an app, set two configuration parameters and then pushed using Git which in turn built, deployed and ran the application. So easy. And all using command line.
Next steps? Send the results to a Google spreadsheet using IFTTT to allow my dad to get the data himself and analyse to his hearts content…
The application is available at github.com/lekkimworld/speedtest and the README explains the whole heroku deployment process.