Hello world!

I just love that title, it reminds me of the first program you ever write in any programming language, first attempted in Basic on a ZX Spectrum by yours truly at the tender age of 11…

Anyway, more importantly, before I ramble on: Welcome to my journal site!

Read more about me on the ‘About Tess Barnes’ page link.

This blog covers more than one area of interest so if you’re here for more than just [code] you might also want to try one of the other categories in the sidebar.

Tips for running Entity Framework (6) and MySQL / Maria

My first forays into running Entity Framework with MySQL have been entertaining to say the least. Each challenge seems to have followed the next and required a fair bit of research to solve so I thought it was worth compiling them all into one blog post. It’s an aide memoir for me and if it helps you readers out too, all the better!

bit vs tinyint for booleans

By default, EF will handle booleans as tinyint under the hood as MySQL in general has no built in concept of true | false other than 1 | 0 and uses tinyint(1) as a substitute. However, tinyint gets treated as byte rather than bit by EF so it’s all a ‘bit’ confusing (ahem, sorry)… Luckily, there is an easy code fix.

symptoms

Error messages usually seen in this case:
System.FormatException: String was not recognized as a valid Boolean..

fix

Add this to your database Context code:

inheritance

Unlike with MSSQL, when using EF6 with MySQL, only one entity in the hierarchy can be concrete – the leaf. This can have implications for your design if you have complex similar entities and want to abstract out those things they share in common.

symptoms

Error messages usually seen in this case:
The EntitySet 'CClass' is not defined in the EntityContainer 'TestContext'

fix

  • Redesign

In a hierarchy such as
MailBox ← ExchangeMailBox ← Exchange2016MailBox
only Exchange2016MailBox can be concrete

  • Manually map inherited fields to the table in your Context via the OnModelCreating method using

unique indexes

Where the design calls for a unique index on a varchar field (e.g. email address) this can be inhibited by strong internal database limits. For the unique index to work on MySQL, there is a max length that must be applied to the field. The exact value is dependent on the collation and database engine used and relates to an underlying byte value.

  • MyISAM allows keys of length 1000 bytes.
  • InnoDB allows keys of length 767 bytes.

On ascii (latin-1), characters are assumed to be stored as 1 byte, giving varchar(767) or above. However, UTF8 collations will store a char in between 1 and 3 bytes. Expect to be able to use max varchar(254).

For keys with collation utf8mb4 or UTF-16, the byte length per character is assumed as 4 bytes allowing a maximum of varchar(250) on MyISAM or varchar(190) on InnoDB.

symptoms

Error messages usually seen in this case:
Specified key was too long; max key length is 767 bytes

fix

  • consider changing your collation; does your internalisation policy require UTF-16 or only UTF-8?
  • consider changing your database engine – loads of StackOverflow articles address this InnoDB vs MyISAM debate, there’s even an article on wikipedia (to be read with the appropriate level of salt)
  • enforce the appropriate maximum length
  • enforce uniqueness programatically (and trust you don’t miss a use case in the code base)

performance issues

Although Entity Framework 6 supports the Find linq method it is not performant and leads to some very inefficient sql query creation under the hood. Big performance improvements can be made by using Single or SingleOrDefault instead.

If you have a complex hierarchy of entities it’s worth considering the question of database policy Table-Per-Heirarchy vs Table-Per-Type. There are good articles out there explaining the difference and suggesting that TPH provides better performance, particularly on Entity Framework. It makes use of a discriminator column which brings its own design  decisions. Historically there have been reports of issues with discriminator columns in earlier releases of EF6 but these appear to have been fixed.

Beyond that changing the underlying database to MSSQL or adopting a different ORM may be your only options. Looking ahead, EF7 does not yet support MySQL and no one knows when Oracle will change this so it’s worth investigating other solutions.

Lazy coding for the win

Its been a while since I wrote any new hook scripts so I thought I would refresh my knowledge before talking about them at phpconference.co.uk. I also love playing around with python – it’s straight forward, pretty and gives good ‘sad puppy’ feedback when you’ve missed a closing bracket.

So I came up with this beast to turn svn log output into a dictionary. You can then do what you like with it: output to a file, turn into html, stream to a feed, whatever.

What can I say, I like understanding things at a first principles level.

Of course then I remembered a cool flag which turns a predetermined text output into something much more meaningful.

xml.etree.ElementTree is the built in python way of handling xml and, again, it’s a bit hand cranked and leads to many unnecessary lines of code. So why re-invent the wheel?

“Has someone already done this?” is rapidly becoming my first question, and yes, someone has!

https://github.com/martinblech/xmltodict

This is the second module library I tried, and is one that can actually deal with lists of elements – essential for svn log output. If you are used to handling things in JSON, it’s really easy:

I have to admit, a little piece of me feels like I’m no longer writing ‘real’ code and that there’s nothing left unsolved or uncoded. The rest of me is doing a happy dance – now we are freed up to use technology to solve the real issues – save time, collaborate well and communicate effectively to make lives better!

Keeping my promise

This was very nearly about breaking my promise, in fact I had drafted a blog post full of excuses as to how my year had been miserable and there was no way I could fulfil my promise of February. Then I panicked, ditched the post and emailed the wonderful and supportive Jenny (@miss_jwo) confessing my failure.

A little while later something wonderful happened, I spotted an opportunity and careless of the consequences, grabbed it with both hands. I surprised myself. A few emails later and phpsw user group had kindly accepted my proposal to give a lightening talk. The talk was last Wednesday night. Their warm welcome was a real testament to the friendly community that is a php user group. I am happy to report I felt calmer than I have ever felt in front of 40+ strangers and I am looking forward to doing it again. So much so in fact, I am considering submitting to other user group nights and even conferences!

Along the way I have learned a few great things about speaking:

  • it’s really easy to arrange
  • it doesn’t have to be a new idea, just your take on it
  • audiences come up with the coolest questions (and tips!) to make you think
  • turning up early wins you brownie points and more free drinks choices
  • practicing your talk to yourself in a spare office the week before is worth it just for the funny looks you get
  • lots of user groups are looking for new speakers of any experience level
  • you might even get your petrol money back

Most of all I got to keep a promise and that’s worth everything.

No shoddy work in the free world

When evaluating a feature for value it’s easy to fall into the trap of equating value with money; direct revenue is not the only value you can get from a feature. Here are some other concepts of value:

  • ease of maintenance, monitoring and admin tools to quickly identify and diagnose potential issues (keep good customers)
  • framework designs can save time adding new features and allow parts of your system to be resold as services (robust resellable software)
  • the right free features can draw customers to your product in the face of stiff competition, gaining you greater customer numbers (get more market share)

The benefit from these features is completely wasted if their execution is ill thought out, is flaky or worse, they don’t work at all.

If you hear that someone isn’t ‘allowed’ to put too much time into a feature because it’s offered for free or its only internal, alarm bells should be ringing. The same key aspects of software should apply here as for anything else:

how this feature should work for each and every user type

Does every type of customer interact with the feature in the same way? Are there staff only actions? Does the feature work in different ways on different tariffs?

how it should be presented and supported

How does the interface appear? Does the ‘flow’ of the feature make sense to the intended audience? What help is available immediately alongside the feature? Is it easy to get to more detailed help? How do support staff learn about this feature?

what design will allow it to be flexible for the future

Does this feature scale appropriately? How much does it share with other features? How often do they change? Do we anticipate offering this through another channel or interface? Is there the possibility of a new type of customer we could be offering this to?

who we should be collaborating with

internal users, infrastructure experts, trainers, support staff, beta testers, external suppliers, industry partners

how we can develop it to be easily maintained and monitored

active monitoring and analysis tools for predictive performance, usage and capacity; intelligent logging and log file analysis; alternative access to feature data including admin tools; api endpoint test harnesses and tools

how we should be testing

when we should be testing; who should be testing; what we are testing for: functionality, usability, performance, load

the most efficient, and least disruptive, release process and cycle

where we deploy, redundancy and failover, how often we release, minimising outages, maintaining reliable and predictable service.

If your free service is mentioned as a big selling point in all the marketing material and brings in twice as many customers, you’ll be glad to have shunned the shoddy and invested wisely in the free world.

How to write yourself positive

What you write becomes the historic record of what happened, if that record is full of negativity, the memory becomes negative.

Apparently, when you remember something, you are actually recalling the last time you recalled it, not the memory itself!

So how do you help your future self out?

Write everything down sentence by sentence. read back the sentence and chop into small statements. more than one and gives you a dividing line. ‘but’, ‘then’, ‘so’ are also clues. Ask yourself do all the parts need to be there? if your record should be factual, without emotion, cut parts that are interpretation, hearsay or feelings. If you are challenging the negative, cut out anything grumpy, limiting or jealous. leave in achievements, benefits and lessons learned.

What you are left with can make you feel uncomfortable right now. This record can challenge how you see yourself and what happens in your life. That’s not a bad thing if you embrace if for the learning experience it presents.

Your edit might also seem terse or disjointed. On the plus side it will be more quickly read and understood by others. Your future self, friends and colleagues will thank you for the time saved. All the more effort available for your next positive experience!

Out from behind the mic stand

Yesterday was the first band practice I took the mic out of the stand and sang with just the mic. It was a revelation. Eventually.

First it felt very scary and exposed. Then I realised I didn’t have to stand up straight, I didn’t have to hold my arms up across my ample busom. I could move around!

Movement is expression, I started smiling, moving my one arm out to my side, opening my chest, lifting my ribs. I could suddenly get more air and that high note I’d been drifting around for ages? I belted it out, I nailed it and the other folks in the band? They noticed (and complimented me, thanks guys :) )

Hiding or propping myself up is easy and safe. It’s something we frequently do to make things ‘quicker’ or easier on ourselves. Props can be tools, practises, services and often people. Blindly relying on dodgy dropping if stands, unmaintained tools, ill fitting practises, out of date services is not going to help progress in the short term or the long run. Assuming that an expert in one field knows absolutely everything, is completely up to date and is senior in every field is darn risky to say the very least.

Not hiding ourselves is scary to start with, we are exposed and seem vulnerable: a bit like butterflies just hatching. But. Not hiding gives us so much more room to play, to experiment, presents us with the freedom to be the biggest and best form of ourselves. We can give so much more, share what we really know and understand.

Coming out from behind the mic stand is much easier than spending hours trying hit a note that a restricted set of lungs will never be able to produce.

So what are you hiding behind that holds you back?

Pausing for thought

Birthdays are always a good excuse for pausing, taking stock and checking life is still on the path you’ve chosen. For fun, and also because I am a curious soul that cares about what other people think and how they measure me, I did a Myers-Briggs test again today.

Apparently, according to my results my most likely careers are writing and counselling and the most important facet of a job for me is how meaningful it is. I find this very interesting in the light of two observations of my early life I had believed for a very long time: that I am a selfish person and that writers must have something to write about.

Times have changed since I first heard those comments, there is an influence on writing styles which has evolved, insisting that 800 words is enough for anyone in one sitting, one must assume that the reader has no attention span and that only one sentence should be used in a paragraph. In addition it seems anyone can write about anything so not having anything meaningful to write about is no longer a barrier. I’m not sure I agree with the turn writing is taking but in my selfish need for permission to write I’m going to take it and run!

 

A Promise

There were some very inspiring keynotes and talks at php uk 2015 which lead me to catch up with many of the speakers. I’ve been a member of the php community since 2008 although my involvement has been very on and off. I’ve a few years worth of experience since then and it’s certainly time I gave something back; so I have made a promise, to Jenny (@miss_jwo), to the php uk community and to you – in the next year I will give at least one public talk.

I have too many ideas to know what the topic will be but:

  • it will be tech related,
  • it will most likely involve php,
  • it will possibly be rubbish but
  • it will be given.

More news to follow…

This weeks lesson : frustration

This last week has been a lesson in frustration – changing requirements, dependency on offshore decision-makers, flakey debugging environments and forgotten code constraints.

These things have always lit a fire under my calm exterior and left me wanting to scream, throw the laptop out of the window and snap at all my colleagues who only want to help. This week was different and it’s a strange (and wonderful) new world.

Continue reading This weeks lesson : frustration

Some things never change

The lessons here are ones I’ve taken a while to learn and they are relevant to coding and most things in life and they have not changed in the six years since I first posted them!

I hope this blog post helps others learn them quicker:

  • Conclusions drawn, even by the ‘wise men’ in a community should never be taken on their own, as gospel.
  • Always check the date of a resource if you can.
    (most of the posts on here are several years old!)
  • Do your own tests.
  • Join in discussions and check your view against that of others.
  • Go back and review your own conclusions after time, has anything changed? new techniques or technology been released? did you jump the gun?
  • Never be afraid to admit you would change your mind (even if it’s only to yourself).
  • Never be afraid to try something new.