DEV Community: Jade Rickerts

100 Days Of Code - Round 1 Days 22 to 28

Jade Rickerts — Mon, 18 Nov 2019 18:55:51 +0000

This past week was a gruelling week for me. I didn't write any code at home or learn anything new from the ASP.NET Core course. All I did was work on new features for JRS Document Storage and fix bugs.

I am under immense pressure at work to release the new version of JRS Document Storage. I have other duties at work that also needs my urgent attention. Thus, when I got home, I wasn't in the mood for anything else. I didn't tweet about my progress. I didn't update my log on Github. I spent time with my family when I got a chance.

I did learn something this week that I can take with me as a developer. Some of these points are conventional and not applicable to software development.

Protecting my time was futile

I am currently employed as a Business Analyst. But, during my tenure, I've given a lot of technical support to our staff. Now that we've gotten to a stage where I have more analysis and development work to do. This part of my job my colleagues don't notice. They come to me with their technical queries, no matter how much I try to explain that I do not have the time to assist.

Protecting my time is a constant battle. Co-workers would first send me an email. If there is no response, they would call me on my landline phone. Then they would call my work cell phone and finally call my personal cell phone if they still can't get me. Those who are in the office, would walk into my office and expect help immediately. Others who aren't in the office will send another office colleague to come to me.

I know there are lots of strategies out there to protect your time. I could have read up on a few of them. But when you have co-workers that only want their problems solved and they don't care about your time or schedule, I doubt anything on the Internet was going to get me out of this jam.

The only thing that I can work at this point, besides ignoring everyone, is working remotely. This is something I am working towards and convince my boss this is the right move. Or with time, my colleagues will learn to respect my time and let me get on with my job.

Getting comfortable with imperfections

As time runs out and deadlines are fast approaching, the need to perfect your code goes out the window. Things get even more stressful closer to the deadline. What can go wrong, will go wrong. You will get error messages that you have no idea how to fix or the solution isn't that simple to implement. You have to let things go and hope you can implement it in the next version.

There were a couple of features that I wanted to implement but I couldn't figure out how to do it. I didn't have the time to research solutions. I didn't have the time to try to put in place those solutions. There was no time to refactor my code and make it look better. I've failed myself but at least I was able to put out something that works.

Planning is vital

Planning is the most important soft skills you need to become a successful developer. I did some planning on the JRS Document Storage application, but I didn't do enough of it. I didn't think through how I was going to update my application when it was required. I didn't plan out the architecture well enough. Now I have to update about 20 databases manually because I failed to plan for a system that will do this.

Going forward, before I start a new project or make any changes to a current one, I have to plan it from start to finish. This will help guide me through the entire process and help me keep my eye on the prize. One tends to work on other trivial tasks or bugs when you don't have a plan of action.

You shouldn't only plan for the development of your code. Planning should include other activities, like designing, testing and writing documentation. I often neglect to make time for the above. When the deadline draws closer, I realise the sheer amount of work I haven't accounted for.

In conclusion

There will be frustrating weeks. There will be times when I want to give up. There are times when I'm not in the mood. Honestly, if I didn't commit to this challenge publicly, I probably wouldn't have made a post. But I have to it. I have to make it all the way through to blog post number 15. Hopefully there will be better weeks.

For more detail on how I did each day, check out my 100 Days of Code Log on Github. Follow me on Twitter for all my 100 Days Of Code tweets.

Until next time. Thanks for reading.

Photo by JESHOOTS.COM from Unsplash

100 Days Of Code - Round 1 Days 15 to 21

Jade Rickerts — Mon, 11 Nov 2019 12:38:11 +0000

Another week down, another blog post. I didn't skip out on any coding this week, but, I did do some coding at work one day instead of at home.

This upcoming week I'll be doing some maintenance on the JRS Document Storage desktop application. I won't learn a lot of new stuff. I will continue with the 5 AM tutorials though.

It gets easier over time

When I first started this 100 Days Of Code Challenge, I struggled to find time during the day to code. Before starting I also struggled to figure what to learn. There are so many technologies out there, it's hard to pick one and run with it.

Now that I've finally started and set a time each day to do my coding, its a breeze. I'm close to halfway through the ASP.NET Core course I found on YouTube. I already know what I'll be doing next. The only struggle now is figuring out what time is best to code on the weekends. I like to sleep in a little on the weekends. I used to get up at 7 AM, but lately I can't get out of bed before 9 AM. By that time, it's a rush to get a lot of things done. But, this past weekend, I managed to schedule in my coding sessions with ease.

Bootstrap and User Interface

I finally added some styling to the web project and its looking good. It's not great, but its something at least. I didn't learn a lot about Bootstrap but I've done a course on Udemy before where I got some practice with Bootstrap.

Bootstrap makes it easy to style your webpage. I prefer this because I am not that great with design. I'd rather spend more time on the backend than the frontend. The Bootstrap classes are also built into Visual Studio's IntelliSense which makes things a lot easier.

Form Submission

I learned how to submit a form. The ASP tag helpers take some getting used to but once I get the hang of it, future maintenance will be a breeze. I also learned how to validate the user's input. In the past, I would use a NuGet package like FluentValidation but all you need to do is include the DataAnnotations namespace. Then you can validate your model and add some style to the error messages in the UI.

I also learned how to upload a file with form submission. This one I still need to get the hang of. I implemented the file upload but I'm still not 100% sure how it works. This is one of those things I'll need to practice a couple of times before I get the hang of it.

Database creation with migrations

Finally, I got to the part of the tutorial where I can implement the database. Setting up the service is simple enough. Using the repository pattern makes things even simpler. You can swap out the different database implementations with ease.

I did come across an error when it was time to commit my first database migration file. Lucky for me, I knew exactly what to because I saw this error in the past. All I did was manually create the database and amend the connection string to include the attach database property. After that things went a lot smoother.

Fixing migration issues is also a breeze because EF Core keeps a migration history table in your database. So if you make a mistake, check that table and revert to that point. It's kind of like Git. EF Core has your back, Jack.

XML to Combo Box

This one I learned while working on a tool for work. The user had to specify the server's IP address. The database connection string was in the configuration file. The users requested for a dropdown list where they can select their store. Most users don't know the IP address of the server. I used an XML file to store the necessary information and then the file is, loaded and added to the dropdown list. This was a bit of a challenge to put in place but I got there. Stack Overflow is a great resource, but you need to know how to use that information in your project. It's not as easy as copying and pasting, which I would never recommend you do anyway.

In conclusion

It was a pretty good week. I made a lot of progress. I can't wait to complete the tutorial. I have a project waiting for me. I'm doing the planning for the project so long so that I can jump into the coding the when I'm done with the tutorial. Developers, myself included, dislike the planning process, but it must be done.

For more detail on how I did each day, check out my 100 Days of Code Log on Github. Follow me on Twitter for all my 100 Days Of Code tweets.

Until next time. Thanks for reading.

Photo by samer daboul from Pexels

100 Days Of Code - Round 1 Days 8 to 14

Jade Rickerts — Mon, 04 Nov 2019 06:57:36 +0000

Second week into my 100 Days of Code Challenge and already I've missed out on a day of coding. I'm pretty disappointed because it wasn't for anything major that I did miss a day. All I did was stay up late to watch Chelsea vs Manchester United and I was too tired the following day to wake up at 5 AM. That one football match was enough to put me off my schedule.

But, I won't dwell too much on the negative and focus rather on the other 6 days I managed to code for at least an hour. Here is what I've learned this past week.

Mornings are better than Evenings

The best time for me to get my hour of coding in is at 5 AM in the morning. It sounds gruelling at first but I've already managed to form this habit. I did a 100 days challenge for waking up at 5 AM earlier this year. This is also the time where everyone else is asleep and I can do what I want without interruptions. On most days, the baby is asleep at that time and if he is awake, my wife is feeding him. But, I'll drop everything if the baby is too fussy and my wife needs my help.

On the weekends when I sleep in a little, I stress a little trying to find a time during the day to schedule my coding sessions. Most of my weekends are usually planned for me. There is always a ton to get done that wasn't done during the week. Or there are some festivities to attend to and planning for that is also a mission most days.

When I do find a quiet time later the day to squeeze in some code, I'm tired because the day took a toll on me. I force myself to get through the coding session, staring at the time hoping the hour elapses soon. This is the opposite effect I want from coding. I want to enjoy it rather than dread it.

Model View is a thing

I've read about the MVVM design pattern. It's mostly used with mobile application development. It stands for Model View View-Model. I've never used this pattern before. I'm much more familiar with MVC, which stands for Model View Controller. I'm guessing that the View-Model replaces the Controller. Anyway, my point is, I can use the Model-View with web applications as well.

I wish I knew about the Model-View class before. It would have saved me a lot of headache in the past when I developed the Document Storage desktop application. Your model doesn't always have all the information required for your view. In the past, I would add the information I needed to that model and ended up with a very bloated model that didn't make sense. Re-using that model for another view presented its own challenges as well. The model-view class is a life-saver.

Library Manager is simple

In the past, I used Nuget Package Manager to add client-side class libraries to my projects. This week I learned about Library Manager which is already in Visual Studio. I didn't explore Library Manager at length but the little I got to use I liked. It is a very simple way of adding class libraries. Selecting the version you want to install is a breeze as well. Updating and downgrading the version is as simple as editing a number in the libman JSON file.

Tag Helpers

This is one of those things I know it will save me a lot of time in the future, but I don't know why yet. I actually do know how it will save me time. If the requirements of your project changes, tag helpers will help in that sense. It's quicker and easier to type out a link rather than use a link tag helper. But when the routing needs to change, you'll need to manually change a lot of links. The link tag helper will do all the changes for you. Put in the work now to save yourself a lot of work in the future.

The image tag helper is also pretty nifty. It helps with the caching of images. I knew that the web browser saved some files on your local disk. Now I know how to do that more efficiently with image tag helpers. The image tag helper will only download newly updated images from the webserver. It will load the local image from the cache if it hasn't updated.

In conclusion

Life happens and we shouldn't forget that. Instead of getting discouraged for skipping a day of coding, I shouldn't be so hard on myself. But I also need to plan for these unexpected events and come up with another way to learn code. I have Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martins on my kindle. I will give that a read if I miss out on my 5 AM coding session.

For more detail on how I did each day, check out my 100 Days of Code Log on Github. Follow me on Twitter for all my 100 Days Of Code tweets. Check out my portfolio website and my blog for more.

Until next time. Thanks for reading.

Photo by Luca Bravo on Unsplash

100 Days Of Code - Round 1 Days 1 to 7

Jade Rickerts — Mon, 28 Oct 2019 10:28:32 +0000

I've committed to the 100 Days of Code Challenge. This is my second attempt. The last time around I only managed to get to about 14 days but then life happened. I decided that I would rather start again then continue after having missed so many days. It didn't feel right.

This is the first post of 15 blog posts about my 100 Days of Code Challenge. I'll post every week what I've learned.

I started off with my 100 day challenge by doing a YouTube ASP.NET Core tutorial by Kudvenkat. YouTube is free and I wanted to see what I can learn for free first before investing money on a paid course.

I like that the tutorials are 5 - 15 minutes each, that means you can go through a video. Going through a 1 - 5 hour tutorial isn't that easy unless you have a media player where you can save bookmarks.

Setting Up My Environment

I started off by setting up my development environment. This was easy because I come from a Windows background and I run a Windows machine. I'm doing an ASP.NET Core tutorial. The Core part means its open source and I can actually use Mac or Linux to set up my environment.

I'm hoping to later on use Ubuntu to develop my next project. But, I saw in the tutorial the instructor uses Visual Studio as an IDE and I'm not 100% if VS is on Linux yet. Its best to stick to the tools the instructor uses. If you run into errors, you won't know if its your tools or a genuine bug.

That is exactly what happened to me. I had the ASP.NET Core 2.1 software development kit (SDK) installed instead of the 2.2. I did download and install version 2.2 and when I build my project, I got a build error. I did the exact same things as in the tutorial, but mine didn't work.

I decided to ditch 2.2 and went back to 2.1 instead. The drawback is that any error I come across I chalk it off to the fact that I'm using a different version of the SDK. For instance, I was learning about the differences between in and out of process hosting. The in process hosting didn't work. I continued the course as if it was working fine.

It's best to follow an up-to-date course to avoid any of these errors.

Learning about the theory

At the start of the tutorial course, the instructor went through a lot of the theoretical stuff. I've done another ASP.NET tutorial before and it didn't go into that much detail. I managed to get a web app up and running in less than 2 hours of following this other tutorial.

Thinking about it now, even though the theory is boring, I do understand much more about ASP.NET Core than I did before. In the other tutorial I used the CLI to build my views and controllers. Now I can create it from scratch. Somewhere down the line when I need to debug my project, it would help to know what's going on under the hood to find and clear those pesky bugs.

Interfaces

I'm embarrassed to write that I didn't use interfaces before in my projects. I know what it is and the benefits of having using them, but my projects were fine without them.

Granted, after I completed a project, I didn't do a lot of maintenance afterwards. Where I did do some maintenance, I could have done it faster had I used interfaces. Who knows, I would.

I used an interface to create an employee repository for an employee model. I'm still unsure how this helps. I'm hoping that a light bulb turns on later in the course when I need to make changes or when I finally connect to a database.

Decoupling

Decoupling is a concept I've learned about in Software Engineering class about two to three years ago. I've never used it in practice though. Now, the instructor mentioned it a couple of times and explained why it is important.

There are three types of ways to pass data from a model to a view. Using ViewBag and ViewData doesn't follow the principle of decoupling. Its best to use a strongly typed view by specifying the model type in the view using @model directive.

Decoupling your objects and methods should make it easier to maintain in the future. There will be less need for changes. Swapping out parts would be a breeze.

In conclusion

I learned a lot this week and I expect the same in upcoming weeks. I'm not too sure how I will blog about what I've learned. I like giving a short summary instead of giving technical details and code examples of what I've learned.

Once I become an expert in ASP.NET Core, I'll write technical blog posts. For now, I'm documenting my journey from 1 to 100 days.

For more detail on how I did each day, check out my 100 Days of Code Log on Github. Follow me on Twitter for all my 100 Days Of Code tweets.

Until next time. Thanks for reading.

Photo by Lukas from Pexels

Web Development - My New Career Path

Jade Rickerts — Thu, 05 Sep 2019 06:55:03 +0000

After some careful consideration, I've decided to change my main area of development from desktop development to web development. It's a decision I haven't taken lightly. It's a switch I've wanted to make for a couple of months now. This was my thinking process behind the switch.

Desktop Development Journey

Firstly, why did I venture into desktop development in the first place. In the beginning I wasn't quite sure which path I would take when I started software development. I just did an aptitude test and recognised that I have a good analytical brain and I knew I wanted to do something in IT. I reckoned that I would figure it out as I went along.

School was mainly desktop development based

I decided that I wanted to become a software developer in 2015 and enrolled in a Computer Science degree at the Namibia University of Science and Technology. I worked as a full-time accounts payable supervisor (and manager later) and studied part-time. Therefore my only development experience came from school assignments and projects.

In school we started off with C# in the first semester. I made an ATM banking console application. The next semester I learned about Java and made a hospital management console application. Later I learned about C++, made a name generator but after that I mainly stuck to C#. All of the applications I developed were desktop applications.

My classmates were also used to desktop development. This just made it easier to collaborate on projects together and this was the best way (at the time) to show off your project to the lecturer.

My first production application

In my final year of studies, word got out at my office that I was doing software development. The merchandising executive asked me if I could developed a simple desktop application. The main purpose of the application was for our business customers to place orders with Metro and to view our entire stock file.

The great thing about this project was that I could work on it during working hours. I didn't have too much difficulty creating this application besides figuring out how I will keep the stock file up-to-date and send changes to the client. Other than that, development was a breeze.

More development opportunities at work

After I completed the Metro Order App and I was put in charge of managing our ERP migration project. I got another opportunity to develop a desktop application for work. The new ERP system that Metro was switching to didn't have an integrated document storage facility. I decided to create one and save the company money in buying an application that integrates. There weren't a lot of document storage applications that did integrate with Metro's new ERP system.

There were more opportunities to develop desktop applications at work. I created a couple of small tools. I created a stock take variance report application to help Metro eliminate the second stock count. There is also the stock mapping tool I developed to help with the migration of the stock data from the one ERP system to the next. Finally I made a small ping app that saves our ping results in a text file that we can send to Metro's ISP if they are having connection issues.

Back-end over Front-end

Just before I developed my first ever production application, I did a web development course on Udemy. The biggest thing I struggled with was the front-end. CSS (and in particular the grid or flexbox) was giving me major headaches. I spent most of my debugging time fixing CSS issues. I was too obsessed with making everything line up perfectly and making elements grow and shrink properly.

When I developed the Metro Order application, I used Windows Forms for the UI. The drag and drop was a breath of fresh air. I stressed less about the UI and focused more on the back-end and getting the project done. This was a big selling point for me. That was the moment I decided to make desktop development (in particular .NET development) my niche to focus on.

Web development is the way forward

It was during my job hunting phase that I realised that I might have made a mistake by choosing desktop development over web development. I looked for local jobs and jobs in Canada (my wife and I were thinking of immigrating there) but most jobs were for web development.

A lot more web dev jobs out there

If I searched for ".NET" or "C#" on LinkedIn and Stack Overflow, most of the results would be for ASP.NET positions. Here and there I would find something for desktop development, but nothing was at a junior development level. I kept on searching until I finally saw two desktop development jobs in our local newspaper.

After the interview process and all the testing, I finally realised that I wasn't ready and wondered if I will ever be. There is just no way I will get enough experience in desktop development if I am not doing it on a full-time basis. Me getting up at 5 AM every morning to do one hour of coding just wasn't going to cut it.

Low barrier to entry

Web development has a low barrier to entry. Yes, this means more competition, but I'm not scared of that. I'd like to think I am a quality developer and companies would be lucky to have me. I just have to prove it to them. If I get my foot in the door, I am sure I can show them I am well worth investing in.

The amount of web development knowledge required to get my foot in the door is far less. I did an IKM test for one of the local desktop development jobs and there was just so much I still had to learn. I made a list of concepts I should have down, but I just couldn't find the time to learn it all.

I have the basic concepts down to build CRUD web applications. I've done it with NodeJS and Express, as well as with Laravel and PHP. I'm sure I'll be able to pick it up very quickly in ASP.NET and MVC.

Money, money, money

With web development there is an opportunity to make some side cash as well. You can do that in desktop development as well, but not a lot of people and businesses out there want custom built desktop applications. A lot of businesses want quick and easy websites. This presents an opportunity to make some extra income for not a lot of work.

Yes, there is a lot of competition out there. Plus WordPress and sites like Squarespace and Wix have made it easier for businesses to make their own websites in-house, but I've read a lot of articles stating that business owners don't really have the time to do this. I've also heard this from a friend of mine, who is also a business owner.

Any device, any operating system

The fact that you can access a web application from any device is the main reasons why I wanted to get into web development in the first place (before I developed my first production application). The bad thing is you need to consider every devices' screen-size and web browser. These days you just develop for Chrome, Firefox, Safari and maybe Opera/Edge, but that is still a lot.

At the end of the day, it just opens up your application to a wider audience. The user also doesn't need to stress about keeping the application up-to-date. That is all done on the server side.

The web is here to stay

The Internet is not going anywhere soon. In fact, more applications are starting to move to the cloud. Soon users won't need desktops any more. All the processing and heavy lifting will be done somewhere else and the user just views the end result on their smart phone or tablet. So there is always going to be jobs and business opportunities out there for web developers. Unlike desktop development which seems to be for big corporations only.

It's a shame I have to leave desktop development behind. I had a lot of fun, but its time for a new challenge. Hopefully I won't regret it.

Until next time. Thanks for reading.

Photo by Alvaro Reyes on Unsplash