Posts

Showing posts with the label software

Technology CV's and Me

I've a small gripe with technology recruiters, if any of you out there are reading this (which since I just cast my CV around, you should be). And this is their penchant for skills lists... I have a very minimalist CV, one page of A4, it covers the primary software languages I like (C++, C, C#) makes mention of my favourite working styles (Agile/Scrum) and it has my history and pertinent academic background. That's all... Minimal, just me, my page one shot done. Anymore and it never, ever, gets me anywhere.  It apparently comes across as "hey look at me" attempts to garner and keep attention with the right buzz words, which I myself despise.  Or it comes over as not having a lot to talk about in the interview, as everything you want to know might very well be in this tome of a CV, and I myself reading them find that I want to ask every question I can in the interview stage, so having it all there you disengage, hurting both your interest in the candidate and their cha...

Kdenlive : First Impressions

They say first impressions count and that's certainly true for any tool I utilize.  In what little free time I've had over the weekend, I've been starting to edit up all the clips I took of the workstation upgrade & rebuild.  This is my passage from the pedestrian Core i7 950 to a Xeon X5670. I've elected to update my video editing software and Kdenlive seemed to be the answer to visual challenges I had at hand, and oh boy was I right. Following a seamless download of the Appimage version, a simple startup and about ten minutes orientating myself, then about a further ten to just get used to the S X and M control core points I was applying effects to clips, setting up spacing in between others and saving to perform a test render. I am utterly and totally so impressed with Kdenlive, this is the first time in a long while I've been equally surprised and delighted by a piece of software.

When Software Tries to be Cute

Image
Developers of the world, unite, and stop listening to sales-folks who say that variety is the spice of life, that you need to make your programs do cute things, like vary the replies it gives.  You are only causing yourself more trouble testing, debugging and annoying your users. Users of the world, unite, and stop wanting stupid cute differentiation replies from programs to make you feel special.  You are not special, you are one of very many using the same program, be like normal people and expect the action of something to have the general same reaction so you can see when things go wrong. I bring this up, as I recently had the Ultimate Ears Blast App, and it was too busy being cute with "just a moment", "hang on in there", "be right with you" bullshit replies to actually work!  Yes, it looked to me they were trying too hard to be hip that actually hit the mark! And YouTube has just done the same thing, check this out.... Same machine, same time, same b...

Crashed my Build Server....

Image
When I say I crashed it, I mean... It just locked up and I had to soft reboot it... And when I say build server I mean one of the virtual machines on one of my Xen Hosts.... So, the machine is a fairly beefy 16 core machine with 48GB of RAM running on a Dell server under the desk, this disk base is a RAID-0 200GB unit over a bunch of 2.5" 10,000 RPM SAS Drives to a Perci5 RAID Controller.... The machine is only really spooled up for big builds, and this was one of them, I wanted to build LLVM support before bed. The problem?  When I performed the build with "make -j all" it would get to 16% and then blank the screen, and totally lock up, nothing, nada, nowt... I left it for a while but nothing happened, and yes the LLVM build is time consuming but it doesn't lock at 16% for minutes. Soft reboot, and the same happened again... I've started the build again with "make -j 15" rather than all sixteen cores.  And it's already up into the 35% area of the b...

Software Development - All Areas Stagnation

Image
It has been said by far bigger and better minds than myself, that if you sit still, if you don't continue to learn about new things and innovate you will stagnate.  This has been a huge problem looming within the business I work, certain things have worked since the industry sector was conceived and even though more than half a century has passed it has largely passed the internals of this industry by. That is until very recently, where market competition has sprung up, the market base itself has reduced and so pressure is on... Nowhere is this more apparent in my industry than on the software, the front-line of pushing product to customers. The trouble however seems to be that many people have stagnated, they've stuck with the safe option, the tools which work off of the shelf, I am of course talking about Windows, the entire tool chain that is used by 99% of the company is all Windows based, I am the man on the spot waving the Linux flag. But just a few days ago, the Windows ...

Development: Design, Prototype then Code

Image
When I were a lad, I were taught to use flow chart stencils.... I was shown how to write data dictionaries, to thought-cloud through the possible data members for these dictionaries, to define the mutable and non-mutable points and abstract away the common elements between these definitions in order to design the code to be written. All pretty much on paper, before you sat before the computer. The reason being?  Paper was cheaper than electricity, and it took a long time to compile and recompile, and then even longer to debug, a program.  Bugs got hidden and only appeared when testing took place. And if a bug ended up in test, which could obviously have been caught on paper, long before it reached the coding phase, then you got egg on your face.  In a nice way, you all knew you had to do more than cut code. Unfortunately Moores law exists, a blessing, and a curse.  As I feel it's made the quality of software design fall, as people can afford to code and compile and t...

Development : Coding Style Clash

I've spoken on these pages before, and even shown, that I generally code to a standard, one of the rules I have it NOT to use Hungarian notation , but to use a notation telling me the scope of a variable, and then give it a meaningful name. Now, over the last few weeks I've been involved in a new piece of coding with a group of like-minded individuals.  And what getter way to explain this oxymoron than through our coding standards. Now, I like to use "m_" for member, lots of people can accept this, I like "p_" for parameters, a lesser few reject this than you'd think and some people even quite like this as they suddenly get to reuse their useful meaningful names, and in languages like Python they suddenly get to distinguish between locals, globals and parameters really easily... But then the controvertial one, the one which causes me most angst. Locals being represented with "l_"... You might say the lower case "L" is asking for troub...

Development : The Cathedral & The Bazaar

Recently I had to explain to a none-developer how we had been working on a project, that is to say he and I.  I explained that our common boss worked very much in terms of the Cathedral, everything is big, grand, old, with set sources for supplies and almost dogmatic adherence to their ways of working.  Whilst he and I had been working, with extraordinary success, in a much more agile manner, in the manner of the Bazaar. Anyone could bring items to us, he could filter some queries, I could filter some others, between us we then worked in an Agile manner to achieve a result. I myself ran the development, and I pushed builds, lots of builds, releasing at least twice daily.  Any problem was picked up, worked on, solved and the next build had it, leaving a train of progressively better builds step by step, until we sit today with a fully functional system and we await input from multiple other sources. The main source for things we are awaiting is the Cathedral, we have ...

Software Development : Get Constant in C++

Image
What does " const " mean to you?  Does it just mean a value can not be changed?  If so, you may want to read on! Const is one of those things, which though not unique to C++ is given more meaning when you leverage C++ fully, const allows you to not only define a value as invariant, but also to instruct other programmers coming to your code how a value should be used, how when it is passed as a parameter it should be treated and ultimately how to protect data from needless alteration, de-synchronisation or simple corruption. Const is therefore your friend, and if you've come to C++ from C, Java, C#, Python or one of the other myriad of languages which don't treat const with as much relevance as C++ you may want to read more than I can say on the topic.  Bjarne Stroustrop (the inventor of C++) and other authors on the topic (notably Scott Meyers & Herb Sutter) explain in much more detail than I ever could, but for brevity here are two examples of const from my own c...

Tech Office: Talking Dress Code

Lets put this clearly, I don't believe in a set dress code (as in defining what anyone can wear) in technology, I've seen anecdotal evidence of the history of IBM where they insist on suits and sock garters and alsorts of things, I've seen companies demand you wear a suit - indeed I used to work in Formalwear production and had to wear a suit - I like suits, however, I don't believe they have a place in the everyday development office. If you're seeing customers, if you're "forward facing" then sure, dress up.  But smart casual is enough for me, what is "Smart Casual"? Jeans, sure.  Shirt, sure.  T-Shirt if it's plain, sure.  What's not... Well, how about a 30 year old sagging woolen jumper?  Please no, just no. What about a bright orange flair neck shirt which has its top three buttons missing and is worn by a hairy chested 1970's throw back?  Please god no. What about shoes?  Well, I wear a nice pair of Rockport leather shoes, t...

Software Development : Failed to get Agile

I've just been party to a conversation about a project elsewhere in my work place, my team is not involved, I was observing passively (alright, alright, I was ear-wigging). The conversation was quite heated, one member of staff was adamant things were fine, whilst another was adamant they were inadequate.  The two of them were at complete logger heads.  The driver of the conversation ran like this: "We're not really designing software, we're asking everyone's opinion, writing it all down and only picking the things we really need to do" As an agile developer this is essentially how I run my team, we write every possible item down, everything and I weight them, schedule them and during out sprint hand-overs we reorg whom is going to tackle diffing parts of the system to share the experience and share different things. This chap however, was incredulous... He expressed "WRITING EVERYTHING DOWN" as a bad thing... He only wanted to do the things he felt ...