Why should and how can we create a dashboard for your project. Or for yourself.

1. 1 / 23
Dashing, smashing,
party crashing
A word or two about monitoring
STANISŁAW ZAWADZKI / VISUALITY

2. 2 / 23
Information is everything

3. 3 / 23
Yesterday is history

4. 4 / 23
And tomorrow is mistery

5. 5 / 23
You need to be in control
●
You never know, when things will go bad
●
You never know if you can trust other people
did things correctly
●
You never know if you did things correctly
●
You don’t want to waste your time to explain
others what you did
●
You don’t want to waste your time to ask
other people what they did

6. 6 / 23
Trust is good but control is
better

7. 7 / 23
Every step you take,
Every move you make,
I’ll be watching
During development, deployment and
production stages we can control everything.
All the tools we use, all services we connect,
everything allows us to gather information
and have a complete knowledge of what is
happening to our system
The problem is what to read and how to
present it properly, so it gives us most useful
information

8. 8 / 23
You should know it all

9. 9 / 23
Solution?

10. 10 / 23
Have it ALL in front of you

11. 11 / 23
Present all that matters
Have all you key development and runtime
factors in front of you. For example:
●
Status of the working system – numbers of
caught errors, response time, last changes
timestamp, etc
●
Status of the development team – how
completing a task goes, if they did their daily
duties, their availability and so on
●
All that you can think of. Sky is the limit
●
If you have to – you may rotate the screens
to ft more information
●
Aaaaand...

12. 12 / 23
Show it

13. 13 / 23
Why so public?
●
You won’t care that much if it’s your internal
tool. But when other can see that you’re
slipping – that’s entirely new situation.
Shame or pride are powerfull feelings :)
●
The more people have access, ther faster
you’ll see a problem if it appears
●
You can share it with the client. Or not. Up to
you.

14. 14 / 23
Some things that you don’t
want public

15. 15 / 23
Transparency vs Flashing
●
You want to show the information, but you
don’t want to expose yourself too much
●
Be careful not to expose confdential
information
●
Present only what matters. You should add a
widget only if it adds something useful
●
Don’t push any API tokens to repository :)

16. 16 / 23
You’re conneted.
All the time.
●
Almost all websites that you use require
registration
●
Almost all websites with registration have
and API access
●
Even if not, you can almost always fnd a way
●
It’s Big Brother, bro. The code you write,
games you play, the music you listen, the
way you take each day – it’s all recorded
somewhere. And usually accessible. It’s so
scarry that you don’t want to think deeper
about it :)

17. 17 / 23
Dashing/Smashing
●
https://smashing.github.io/
●
Sinatra based
●
Few default widgets to present data
●
Many Open Source widgets
●
Possibility to confgure each widget all with
cofescript/css
●
Possible authorization

18. 18 / 23
Dashing/Smashing jobs
●
One job for each widget
●
You need only to fetch data and pass it to
proper widget
●
Timer confguration – some information you
want very often, for some once a day is good
enough
●
Rufus Scheduler for cyclic running
●
Data required on specifc widget may vary
●
Customizing size and position of widgets

19. 19 / 23
Widget defnition

20. 20 / 23
Extra features
●
Drag&Drop widget customization
●
Extremely easy heroku deploy
●
Pushing data possible (instead of default
pulling)
●
Possible graphic enhancements
●
And everything else that Sinatra or JS allows
you

21. 21 / 23
Widget Data

22. 22 / 23
And here we go

23. 23 / 23
Thank you!