Back to Website
Kerri

A search for words, fonts and icons.

Posted January 4, 2017 at 11:10 AM by Kerri

Posted in: Antelle

Hey there! 

It has been a couple of months since my inaugural entry to this blog and since then I have accomplished a couple of things.  I've approached Web APIs and MVC in asp.net, which I was able to use to program a wordsearch generator and I've most recently I was tasked with creating a web service to turn an icon webfont into a somewhat customisable package of png images.

The Search for Words

The wordsearch was admittedly more difficult than I had initially suspected it to be, I learnt a lot about how MVC works in .NET through it's development however and found it to be an enjoyable experience. I approached it by detailing the logic with pen and paper, logic for which had to meet specific requirements. "Words need a minimum length", "Words can only intersect one other word." and "Words should be reversible, a percentage of which is defined by the user.".

I got most of the logic working with my initial attempt, but was unhappy with the presentation of it and the lack of flexibility. I was using the razor syntax to write the wordsearch to the page in a table, and using CSS3 psuedo-elements to draw the solution. This method wasn't printable and couldn't be easily configured into an actual game. Behind the scenes a lot of the code was basic, immutable and bulky so I revised it by attempting a more object oriented approach by handling state changes of objects through the controller allowing the controller to handle just the logic. I will admit this level of detail was likely unnecessary and potentially overkill, however it taught me a lot about how a more complex C# application could be written.

For the presentation of this view I opted to use the HTML5 canvas element and javascript populated by the razer syntax in the view so that I could create a more dynamic and reliable representation of the wordsearch on the page.

Font Imager? Icon Packager? Webfont Icon Generator?

You can read more about this here http://blog.antelle.com/post/building-font-imager 

Overall...

I'm happy with the progress I've been making. I'm looking forward to becoming a certified developer at some point, headway on which I am planning to make as soon as possible and I'm hoping my future tasks will provide just as many opportunities to discover something new like Attribute Routing for Web APIs or HTTP headers as a solution to a problem.

 

Thanks for reading,

 

- Kerri

Kerri

An Introductive Summary

Posted October 25, 2016 at 9:36 AM by Kerri

Posted in: Antelle

Tags:

Hi, I'm Kerrigan, the newest apprentice at Antelle. 

 
Today marks my thirtieth day with the company, and my first month started me off running. Whilst I'm not particularly new to programming or website design, I am new to the microsoft stack and I spent the first two weeks knee deep in Pluralsight courses. 
 
It didn't take me too long to ask for a task to complete and so I was given one. The task in question was to provide a word search generator written in C# using the MVC framework. 
 
Now, previously being a PHP programmer, MVC wasn't a new concept to me. It's a pattern I'm familiar with, and one I've had experience with. However, the C# approach was vastly different to anything I've seen before with so many IDE shortcuts that it took a while to get used too. In an early attempt instead of passing a view in my controller, I attempted to redirect to an action and carry the model along through a get request accidentally and spent two days trying to figure out why the model wasn't serialising. Not my brightest moment. 
 
 That being said, within a couple of weeks I submitted it for my first code review and besides my consistently incorrect conventions there were very few things that needed discussing. Mostly just proper use of private, public and internal access modifiers as well as a major logic loop I'd set up as a for loop with moments where the loop iterator would decrement itself in order to take a step back. I was advised to alter the loop to use a while instead which was something past experience in other languages I'd been advised to avoid. The changes were made and the program still functions as expected. I tidied up some classes, cleaned up some functions and rewrote method comments using the C# guidelines. 
 
There's still plenty of adaptation to go yet, how and when to use delegates for example, or even just memorising all the IDE shortcuts in visual studio. It's not that I've never used an IDE before though, I've used intelligent text-editors with intellisense and CTags as well as auto-complete and snippets along with package managers, but none of them have been able to do as much as VS can at compile time to improve programming efficiency. 
 
To me it seems that the .NET package is less about traditional programming and more about following the conventions. Which, whilst well documented, are difficult to get used too when you've been a programmer in the past writing your own PHP frameworks because the existing ones don't work, are too bulky or are missing a feature you deem vital. 
 
To support my opinion I've been introduced to Umbraco. The go to .NET CMS, which unlike Wordpress offers far more in customisability when it comes to what kind of content you can produce and despite all the options available to you, it offers one of the largest groups of users who all seem to be able to integrate with each other because of the conventions that have been developed. 
 
So that's my experience so far at Antelle, despite being a programmer prior to starting my apprenticeship I believe that there's always more that can be learned and the best way to learn is by doing. Looking forward to my first exam on JS, HTML and CSS too, as those are topics that I feel I'm more than capable of but have never been certified in. 
 
 I guess this it for my first blog entry, no doubt there'll be more in future.
 
 - Kerri
Ben

Web API: A Song of Trial and Error

Posted September 1, 2016 at 1:12 PM by Ben

The Middle Man

It is easy to leap from input to output when it comes to data.  Anyone could draw a bar chart based on a spreadsheet.

When anyone does that they become the equivalent of a Web API without knowing it.  They look at what needs to presented, they trawl the spreadsheet for the correct group of information and then return to the bar chart and with that information in hand.  Only then can someone begin to work.

I've written posts about the front end of a Web Service, a variety of situations involving data, I've written about retrieving data from an API that I have then used to overlay information on a Google Map. 

You can probably see where this is going, I've used them, designed things with the use of an API in mind.  Until recently however I hadn't rolled my sleeves up and built my own.  I made many mistakes, turned out builds that were completely and hopelessly inept at their desired function.

Now, however I have something that works exactly how I want, something that can do the whole range of Create, Read, Update and Delete (CRUD).

Lessons Learned

The Big One

Direction is really important, it's no use setting out to plan and build a Web API without being at least 95% sure of what it needs to do for you and anything that interacts with it.

I'm close to doubling down and posting a multi-part overview of the project this API was built for.  The mistakes and successes of that work came very much so due to initially having a poor idea of what I wanted and needed to build, that was the entire project and not just the API.

By meticulously planning out the source of your data and what the final product of your API needs to be you can save yourself an astounding amount of pain and frustration, never mind the dozens of StackOverflow visits every hour when your API isn't behaving the way you need it to.

Mistakes are going to happen. Embrace them.

At various points throughout building this API I made amateur-hour mistakes.  The code review was full of disbelief at some of the poor approaches I took to achieving the desired effect within Controllers or Models in the API.

At the time, these methods were operational, they definitely worked how I wanted it to do things, looking back now I can shake my head in disbelief as well. Refactoring code is hard when you don't know better ways to approach things and more often than not the best way to learn is to fail.  You're failure is only complete when you don't learn from it.  In this case it wasn't a case of a slight misuse of a method that could have been solved another way, it was a complete failure to understand manipulating data in a correct and clear way.

On to the good stuff


This Web API takes HTTP calls to do it's work.  POST, GET, PUT and DELETE. These correspond to the CRUD functions.

POST sends a JSON object containing all of the information that a record holds, this object is built from user inputs to create a new record in the database.  When the JSON object arrives it maps itself to the "Update" object and it's properties and that object is then used to construct an INSERT statement in the database and write a new record.

GET retrieves a group of 15 records from a database when given a page number and delivers those back to the web page to be displayed in a table.  Each of these 15 records is added to a list of Record objects and they are then returned to the webpage as a JSON object.

PUT receives a specific record, however that record comes with new information that the API must tell the database to update with.  As with POST this JSON object is used map a new Update object that in turn is used to construct an UPDATE statement where the UpdateID of the record is passed in the WHERE clause to change that record only.

DELETE receives one thing, the UpdateID of the record the user on the front end is trying to delete, a simple DELETE statement WHERE the UpdateID is matched is deleted, this is unique across the CRUD functions of the API as doesn't require any objects to be constructed, the only thing being passed in is an int value.

Routing

With ASP.NET there is an option to change how API calls work from the front-end.  In the case of this particular API, first the API's host is listed, then the API, then the controller, then the method. Optionally the user can pass in an integer at the end of this call as data.  A final URI (Uniform Resource Identifier) would look like such: "www.examplehost.com/api/updates/delete/4".

This URI would result in the API deleting the record with an ID of 4.

Routing is controlled by the designer of the API, I could have set up those URI components in any order I wanted just to mess with people but alas such things are frowned upon.

The worst possible Analogy...

I spent far too long thinking of a way, in layman's terms of how I feel about the interaction between a Web API and the Front End it is being used by.

So, imagine if you will that the front end is a screw and the API is a screwdriver.  You have the screw you want to use and you look into your toolbox to see what screwdriver will get the job done.  If you reach in blindly and pick out the first screwdriver you find, you've got a pretty big chance that it won't work, a small chance of picking out something that will do the job adequately and an even small chance of nailing it first time.

Understand that this works both ways, if you're using a Web API that has been around for years you may need to change the screw to get the front end to work.

The better a match for your Front-End the API you use or design is the less hoops you have to go through to get to where you need to be.  It's always worth checking out alternatives to see if what you're using isn't what's right for the job.

Conclusion


It's a weird and wonderful thing to be at the stage of my training where I can be asked to visualise, plan, design and code a full web service, albeit a fair amount of poor work going into that service.  It's in equal parts a measure of how far I've come in the past year and of how much more ground there is to cover ahead as I go on from here, there are new things to learn in C# every time I try something new.  As I often repeat myself saying, it is up to me to try to cover that ground moving forward.

One full year, it's hard to think about the sheer density of things that have happened both in work and personally over that time since I first turned up to Antelle.  I'd like to think good things about that time for the most part, ignoring the flooding of our old office of course. I prefer to look back on struggling with the first HTML assignments, of getting my first web page finished just a few months later.  I think I'm settled and in a position to push myself further and start helping with other projects more, to see more of how the most complex projects are designed and planned.

Until the next time, thanks for reading.
Ben

C# and becoming Trilingual

Posted May 19, 2016 at 12:36 PM by Ben

Show Antelle

Get it?

Anyway, I took part in my first demonstration to a client of a product, the product in this case being the close to finished version of the Umbraco website I mentioned in my last blog post.

Bugs, bugs everywhere.

I was surprised at how, despite my best efforts to try and break my own work, it only takes one person saying: "What happens if I do this?" and everything seemingly comes apart at the seams. To detail a few things; the navigation bar had an odd bug that would add random empty unordered sublists after certain pages, the CSS controls I added to prevent certain content elements from breaking the page didn't do as much prevention as I had hoped and the responsive page sizing wasn't quite as perfect as it could have been.


That said, if the presentation had gone perfectly and these errors hadn't been found, my first real published product would have been fraught with minor bugs, which I'm obviously pretty eager to prevent.  So a bit too much pointing at a screen and saying: "Yes I'll fix that as soon as we're done." did have some positive effects.


As well as exposing bugs, I got some valuable one on one insight into how the customer wanted certain things to work, whether that was more CSS controls for him to use in controlling the content via Umbraco or a minor aesthetic tweak to how the header would display.

I'm confident that when the website is released he will be very happy with the final result, featuring the lovely clean look of Bootstrap and the capability to fit on any screen, big or small.


Sticking to the Program

The road map for my time at Antelle now has me firmly into learning C#, a universally used and extremely powerful language that is opening my eyes to the power that words in a file can apply to the real world.  So far I've only dipped my toe in the proverbial pond of C# and it's been a blast so far.

I think Tony has been reading over my last blog post and saw that I what I said about my learning process and promptly handed me a task to solve.  As I write this I've "finished" a small program that takes an XML file containing various queries to be passed to SQL Server and returns data that is then converted into a CSV format.

Making this program has taught me two important lessons at the very least:

Bigger isn't always better, at various times throughout making my first actually useful C# Tool I tried again and again to over-encapsulate my work, most of my source control comments at the mid point of the Tool's history tend to be:

"Added working classes for XYZ"
Shortly followed by:
"Working classes for XYZ removed, pointless"

Through learning resources it was emphasised again and again how important it was to try and use classes to make everything organised, to encapsulate things as it is a good practice for C# developers.

While this holds true for much, much larger programs than my own.  It only ended up confusing me by making a Class with very little too it and then referencing three class in a row in my main program, with something this small it really is not necessary to over-encapsulate.

The other thing I learned is that if I'm looking to add something to my program, odds are that someone far more talented than me (for now) has already made a framework for it.  In this case it was logging errors to the Event Log. I tried to do it on my own for a brief period, resulting in some humorously mind boggling issues with eternal errors refusing to ever stop being passed on.

So, I switched to a framework at the behest of Tony, and no surprises with what happened next, my work was done far, far quicker.

Thanks for Reading

Come back for more ramblings soon!

Our Commitment

We strive to deliver a level of service that exceeds the expectations of our customers.

If you have any questions about our products or services, please do not hesitate to contact us

Microsoft Silver Partner in Application Development

Stay Connected

Antelle IT Ltd
Unit 17b
Carrs Lane
Tromode Estate
Douglas
Isle of Man
IM4 4RG

Phone: +44 (0)1624 660613
Email:info@antelle.com
skype:antelleit