Nobody likes it. They are boring duty you ought to do after a meeting. What? "Minutes", of course.
By "minutes" I mean: a note from the meeting (or a telco) that should be sent after a call to all participants involved in order to remind what has been agreed on the meeting and what action items are specified and who is responsible for implementation.
Is there a way to make this very useful tool more effective? The answer is: YES!
First of all: lets enumerate expected properties of those "minutes":
- easy to write
- do not skip/forget anything important
- allow to control if every action item has an assignee
Having above properties in mind I've implemented the following process using an online documents solution (Google Docs, to be specific):
- I send proposed agenda as online document link to every participants and I allow them to extend it if needed
- During the call I (or any participant) add action items and responsible persons to the document. Remember: concurrent editing is fun!
- A copy the document is sent after the call in the same e-mail thread as invitation
- And now: the previous step delivers your team "minutes"! Voila!
Everyone has R/W access to the document and this is the gag – you can delegate your job to add notes and complete document (including completeness checks) to meeting participants. They enjoy that as they're involved in the meeting flow and the output directly. Nobody is bored.
To speed things up you can add timestamp to each agenda item. Such meeting could never miss allocated time!
Implementation tracking is also easy – you can add ticket tracking ID (Jira, Redmine) to the minutes and assign appropriately.
Happy (not boring) meetings!
Posted in en
EDID stands for "Extended Display Identification Data" and in IPTV solutions is used to provide detailed information on TV set capabilities and manufacturing information. HDCP ("High-bandwidth Digital Content Protection") is used for protecting high resolution content from being stolen by DVR. We typically count failed and successful HDCP connections. This data is usually reported to central server using TR-69 protocol and/or proprietary protocols like Agama.
STB (Set Top Box) devices usually run from NAND partitions. All the rootfs is persisted in read-only filesystem (squashfs) and mounts additional R/W locations if needed (ramdisk for /tmp storage, at least). This setup works quite well for final deployment, but might be a bit problematic if you, actually, develop software stack and need to update and test many times per day.
This is the place where long-time forgotten network boot method comes to play.
In the old days (university) I remember "thin Solaris clients" that were used for programming classes. They had no hard disk and booted from network. What the boot process does look like?
Posted in en
Tagged iptv, STB
Few, most important in my opinion, however mostly overlooked GCC compiler switches:
- -Wall: enables all the warnings about constructions that some users consider questionable, very likely a programming mistakes
- -Wextra: enables some extra warning flags that are not enabled by -Wall
- -Winit-self: warn about uninitialized variables which are initialized with themselves
- -Wold-style-cast: warn if an old-style (C-style) cast to a non-void type is used within a C++ program
- -Woverloaded-virtual: warn when a function declaration hides virtual functions from a base class
- -Wuninitialized: warn if an automatic variable is used without first being initialized
- -Wmissing-declarations: warn if a global function is defined without a previous declaration
- -ansi, -std=standard: specify the C/C++ standard level used
- -pedantic: issue all the warnings demanded by strict ISO C and ISO C++
and the most important one:
- -pedantic-errors: turns warnings into errors, so your build would go red in case of any warning
I must admit we used to use "pedantic-errors" extensively for many years and many pitfalls are omitted then automatically.
Default git colour setup is not so good. On black terminal background it looks dark:
However, with small change in ~/.git/config file:
meta = yellow bold
frag = magenta bold
old = red bold
new = green bold
you would get much better diff display on your terminal: