3 Important Programming Tips (that every student should embrace)

1. Immerse yourself in the coding universe

Commit to spending time in and around others that do the kind of tech stack you are learning, and do it right away. For example, the quickest way to learn a foreign language is to live in that country and expose oneself to people that speak the language. There are nuances and cultural pieces of information to be gleaned from this approach and cannot be reflected by formal instruction alone. Go to user groups, participate in things you know absolutely nothing about but are curious and driven enough to figure out. One thing we all have in common is our passion for tech, so connect with those that can share insight. This requires a commitment outside of your school or job hours, but is well worth the effort over time.

2. Ask why before you ask how

If you have come across a particularly confusing piece of code to learn, ask for clarification as to WHY you would use this in the first place. Code without context is not helpful to anyone, not every course is written perfectly, and some are better coders than teachers. Understanding the why will help you know when to apply this technique in the future, and allow you to speak intelligently to other programmers about your opinions on the approach. It is he best way to file it away for later in your mind. An added bonus to this question is that it can send you down an alternate path, if you find the answer unsatisfactory or unclear. Often I have discovered some of the coolest plugins, libraries and frameworks this way. Don't be a lemming - think for yourself. Don't just accept that you have to bang away at some code - know WHY you would do it first. If you don't get a good answer from your teacher or the self-paced course you are going through, put on your detective hat and make some discoveries of your own.

3. Never, ever quit

Mastery of a subject varies in length from person to person. What may seem hard for one is easy for the other. What took 2 years for you to learn one can take 6 months for another subject. Programming is not something you are born doing - you learn to do it. So never, ever quit persuing your passion. You will make more mistakes than you ever thought possible before you can stablize to some true successes. There is no time limit on finding your groove as a coder. Regardless of whether or not other people think you can do it - you can. Those eureka moments are worth every moment of the struggle it takes to get there. So when you are trying your hardest and still not getting that program to compile - take a moment, refocus, walk away - and then return to it. Shift your perspective and approach until you find the right way. What makes a great programmer is an subjective question - but one thing is for sure, they are never made overnight. Be hungry for the solution and resolute to finding it. Many of us have no idea what we are doing when we start on something new. Don't worry, you aren't alone. What will make you stand apart though is your drive and tenacity to figure it out.

It's time to declare war on "Hello, World"

Whoa there. Harsh title? 

Perhaps. War is such a strong word. However, through experience, I have reached the conclusion that this teaching approach cannot be tolerated anymore, and forceful removal is necessary. Stumbling blocks being what they are in this industry, I feel it's time to talk about this, and without any beating around the bush. Let's start with an analogy:

Danny wants to be a board game player. He looks up how to play a board game on the internet. He selects checkers as it's a simple game to learn for someone new. After playing the game a time or two, he feels confident enough to sign up for a beginner board game competition. He is assigned to play chess - which is also a board game, so he figures he can apply what learned from checkers and figure it out as he goes along. His first turn, he moves a piece and feels good about that. The next move that ensues from his opponent leaves him scratching his head. He doesn't understand it exactly, so he decides to shake it off and move another pawn. That's how he learned to do it with checkers, so it can't be that different. It's just a board game. The game progresses with each move from his opponent removing his pieces, one by one, and he can't seem to confiscate any of their pieces in return. Even though he was moving his pieces forward, he didn't understand that each TYPE of piece represents different levels of capabilities. Before he knew it, he was outwitted and checkmated. All he knew was how to move a piece forward one space, like in checkers. But this was not checkers - this was chess. While both games, on a board, with some movement - how you get to the end of a real game is vastly different.

Danny failed to learn the strategy and approach to the game. 

This is what new developers, or experienced developers switching to an unfamiliar tech stack, experience often. As teachers, we believe in breaking things down to it's most basic and simple level. When presenting a quick reference of help, like on Stack Overflow or in the comments section of a blog, this approach is welcome. But when you prepare a tutorial, article, video course or speaking session, you have a greater responsibility to show a more complete application.

Wait a minute. Hello World was not designed to teach people design patterns and architecture. It's just to communicate a small example of what a particular thing does. Why is there a problem with this?

Teaching how to do something that is REAL WORLD in how you would be expected to execute it shouldn't be a concept that we leave behind for the sake of brevity. Documentation examples are notorious for this. One of the fundamentals of clean code is to handle naming in a human readable fashion, as robust as is necessary. Most would agree that getTimezoneAbbreviation() is clearer than the shortened version getTAbbr().

I don't have time to arrange the holy grail of teaching courses. I'm just going to put all my code in one file so I don't have to worry about a bigger structure. As long as it runs and proves the point of the functionality I'm showing, I call it good.

Sure, you could do that. In fact many of the authors of instructional code do this. It doesn't make it good for the student to learn. Why set up the learner for failure? It doesn't really take that much longer to JUST DO IT RIGHT in the first place. At the very least you show proper placement in a real environment, and what kinds of hurdles will have to be overcome in relation to the rest of the application. In addition you also educate, indirectly, how good architecture can work. Reinforcing the fundamental best practices of thoughtful development is the responsibility of all of us. Why take time out to do it any other way? Common sense programming doesn't exist until we make it commonplace.

The reign of Hello, World has had it's time, but a new approach should be considered that can assist the learning curve and make more sense. That is a tutorial style I know I'd be more likely to dive into. Therefore, I issue everyone the challenge to craft more of your examples this way whenever possible. Perhaps we can refer to it as:

Hello, Real World.

Because context matters.

Compatibility: Xamarin Forms 2.0 and UI for Xamarin by Telerik

The new year brings new changes to the Xamarin framework, and most notably the Xamarin Forms abstraction library. With the release of Xamarin 4 and Xamarin Forms 2.0, we have inclusion of Material Design for Android, a new API for ListViews, enhancements for Windows Phones, lot of extras and of course much needed bug fixes. It's a solid release, and looks to make the use of XF even more efficient. The upgrade looks perfect for what is in demand right now.

Sounds good, but I still dislike messing with the visual design. Are there any other options?

Enter UI for Xamarin by our friends at Telerik. Although the Android and iOS libraries were presented previously, support for Xamarin Forms was released in late 2015 with a basic set of controls. More are being added quarterly. They bring the familiarity and ease of their Rad controls to a Xamarin mobile app (if you have had any experience implementing them on .Net applications, they are second to none in quality). You can find out more about the plugin here.

Fantastic! I'm sold. Plugin trial downloaded, Xamarin project started, I'm only gonna focus on Android for now. Adding the plugin references and... wait, why won't my project build?

At this time, UI for Xamarin is compatible with the previous version of Xamarin Forms. Since 2.0 is so new that it just came out, Telerik has not had a chance to test their plugin against it and make it compatible. Do not be dismayed, fellow developer. It is still possible to try out the suite of controls with a few extra steps (which ultimately should be fixed in the next release).

Things you need to know:

• When you download Xamarin 4, you get Xamarin Forms 2.0
• If you use the Visual Studio plugin for Xamarin, the project templates have old references to XF, so a package update via NuGet would be necessary anyway
• Telerik's UI for Xamarin compatibility is only for Xamarin Forms version 1.5.1.6471 [reference]
• You will need the most recent Android SDK (API 23) installed

How to run UI for Xamarin in Xamarin 4

For this example, I choose to set up the app for the Telerik Xamarin Forms ListView control.

1. Create a blank Xamarin Forms Portable app in Visual Studio

2. Uninstall the existing version of Xamarin Forms that is shipped with the visual studio project template. Note the version.

3. Install the Xamarin.Forms NuGet package (must be version 1.5.1.6471 - done through the Package Manager Console in Visual Studio) to the PCL and platform-specific projects. See NuGet command.

4. Add references to the UI for Xamarin Forms controls from Telerik to the PCL and platform-specific projects as you need them. Read the API documentation for specifics about using the ListView control, for example.

5. Pay close attention to what additional NuGet packages are required for the Android project to get up and running using Xamarin.Forms. There is an excellent blog post on installing the necessary references for the Telerik ListView for Xamarin Forms here.

6. Build the project to make sure you are ready to proceed with building your app. If you still find issues building, make sure to clean and build. It may also be necessary to open the bin folder of your Android or iOS project and delete anything that was previously in the Debug folder before building again (thanks to the Xamarin Forums for that suggestion). I only ran into that once at the beginning of this process. After that, no problems with running the Android app.

Eureka! We got a welcome screen. Is this something that could happen again, or just for this version?

Always Be Prepared

Handling compatibilities between software can be a bit of a bear, to be sure. With the ever-changing landscape of mobile apps, we want the growth and enhancements to occur. Seldom does it come with easy integration into existing technologies. But take heart! It won't be long before subsequent min versions should be able to clean that up for us. In the meantime look at it as an opportunity to examine how the fabric of a Xamarin Forms application is woven together with third party plugins. Knowledge that will certainly serve you well in the future.

The SPROC Stress Buster: SQL Table Types

Most recently I worked on a .Net project that required a layer of database obfuscation by working with stored procedures and not the data tables directly.

...Say what now? Why not just Entity Framework for my data access layer like normal?

There are several reasons you might find yourself in this position. Perhaps the DBA does not want to allow you to write records at the table level for added security or you might be batch processing a lot of rows at once... or perhaps the database is in such a state that accessing views might be more preferable. For this project, that requirement meant eliminating Entity Framework as an ORM option for the application - as it requires direct access to the schema in order to reflect the data objects properly.

Translation: Now I must think about database work a little more. 

Kind of a pain in the easy world of plug and play EF. There are always trade offs when determining which architecture piece is the priority: ease of development or additional security approaches. In this case, I needed to put my DBA hat on. The solution involved utilizing a Micro ORM that would execute a stored procedure a layer above the individual tables in the aforementioned SQL database. For this approach a micro ORM was selected: Dapper - the lightweight, quick and nifty framework that allowed you to handle CRUD in a variety of ways with anonymous objects (important if your ORM will have no true knowledge of the database schema).

Re-thinking Repositories

I had several rows that needed to be inserted in bulk. In other words - I didn't want to insert the rows one by one. The performance would be nasty. I had an average of 50 rows to insert all at once that a stored procedure would need to handle. So how do I hand those off to the SPROC within my data access layer in code?

This is starting to sound complicated. Can I give a stored procedure a collection of objects?

Why yes, yes you can. With a table-valued parameter, utilizing user-defined table types.

Great!...What does that mean and how is it done?

It means you decide what the object properties are at the SQL level in the User-Defined Table Types folder in the database (see screen shot below) and that is the data type the stored procedure will expect to receive as a parameter - the entire data table. You just model it after the object you are sending.

What does a database-level data type have to do with Entity Framework's capabilities?

At the time of this project (early 2015), EF did not support user-defined table types. It does not import them from the database and convert to a virtual object that you can access in code and then hand off to an ExecuteStoreProcedure() operation. So, I would loop through my objects and painfully, individually insert them one by one... but this post isn't about the ORM choice (which are ever evolving and add features all the time) - it's about understanding and harnessing type tables to handle your bulk lists of objects and insert them in ONE TRANSACTION.

Why do I care about inserting rows in one transaction? What's the big deal?

Depending on the amount of data, bandwidth. Give it all to the SQL database and let it do the lifting - that's what it's made for, handling large amounts of data. It's important to realize what is going on when you call an Insert() in an ORM. When it comes to scaling up larger data sets, sometimes you need to get your hands in deeper to get more control over the end result.

A Little More Effort for a Lot More Efficiency

This approach is a bit more hands-on but I'd argue that until I did a project like this I never really thought much about how to make data insertion more efficient. Now this is something I can really utilize for shuttling a list of objects to a stored procedure. Table-defined parameters are a great option.


Editor's note: See this post for an excellent how-to with a NuGet package that you can now add onto EF that will handle part of this for you.