The A to Z of App Development 2018

app development 2018

Here’s my next post which appeared first on Simple Programmer.

Apps (short for applications) were introduced to the world via the iPhone in 2007.

In 2008, the Apple App Store was opened, and anyone could create apps. A market had opened that could generate developers enough income to give up their day jobs.

Now, there are two major app stores, Google Play (for Android apps) and the Apple App Store (for iOS apps). Together, they host close to six million apps. This is a massive growth rate in 10 years. And with the next billion users, it’s set to grow even more. Who are the next billion users? They are the next wave of users of the internet. They likely reside in third-world countries that previously didn’t have great infrastructure. However, countries within Africa, where users were previously unconnected, are becoming connected with the construction of 5G networks. This means that these users will need apps that cater to their own needs, wants, and entertainment values just as more developed countries have done over the last 10 years.

Since the creation of apps, development and distribution of these applications has become more complex. Their quality has improved, competition has become fierce, and the ways to develop them has become more diverse.
If you’re new to app development, I hope to give you a brief insight into useful information about apps and smartphones through what I call the A to Z of App Development.

App Store Optimization (ASO)

ASO was introduced to us via the Apple App Store in 2008, but it wasn’t regarded as an important business practice like its older sibling SEO until quite recently.
ASO means you are optimizing your app to be easily searchable in the app stores using specific keywords. Tools like Google Keywords exist to help you find the highest ranking keywords (which are the most searched for) within a certain category. By associating the keywords that are searched for the most with your app, you make it more likely that your app will appear in search results for users.

In order to add keywords to your app, you need to enter them into the appropriate field within the developer console profile of your app in an app store.

Bluetooth

Bluetooth is the wireless communication technology that allows a minimum of two devices that have been paired to connect and share data over short distances. This method is the most common way to connect audio devices with portable devices such as laptops, smartphones, and tablets.

It was invented by Dutch electrical engineer Jaap Haartsen in 1994 while he was working for telecom vendor Ericsson. Now, it’s commonly used by all companies and industries to connect their products.

Cross-Platform

When apps were first introduced, you could only develop an iOS app using Objective-C or develop an Android app using Java. This led to many developers specializing in one platform, and while it was good for developers to know the ins and outs of a single platform, it blocked them from reaching the user base of the opposing operating system. It would also double the cost of an app for those wanting to purchase the development of an app for both stores.

Now, there are a number of solutions that enable developers to code once and release to all stores. We call this capability cross-platform. There are two main ways you can create an app that’s cross platform:

  1. You can create an HTML5 app that allows you to code the app using web technologies like HTML5, CSS, and JavaScript. This is the wrapper that’s compiled into either platform’s codebase in order to make it run on the specific device.
  2. You can use a cross-platform tool like Xamarin or Unity and code the app in C# or JavaScript depending on the tool you use.

Cross-platform enables developers to become specialists (at a high level) in both platforms and reach more users. And, of course, it allows for the potential of more profit.

Devices

In app development, there are currently three key devices to develop for:

  • Smartphones
  • Smartwatches
  • Tablets

Smartphones, as I mentioned earlier, were introduced on a large scale to the world when the iPhone was released in 2007. Tablets came next, and again, Apple seemed to succeed in this wave of advances, even though Android tablets were available.

The apps for smartphones and tablets can be shared so the amount of work needed to develop across the devices is minimal. However, if you can, it’s a good idea to develop a difference between your smartphone app and your tablet app. (You may find that tablets should have a different layout to make the most of their screen estate.)

In 2015, Apple released the Apple Watch. It has several iterations, including branded editions like Nike and Hermès. Android watches have been released since the Apple Watch by companies like Samsung. These small devices, unlike tablets, cannot share the same app as smartphones. Because of their very small screens, individual apps (or one complementing your main app) must be created. Different interactions will be executed, and visual designs for smaller screens need to be considered.

Emulator

Emulators are software that allows app developers to test their app without launching it on a physical device.

Testing on physical devices should always be carried out when developing apps, but because of the fragmentation that exists across mobile devices, having access to all the different devices that your app can work on isn’t financially a good decision.

Emulators allow you to set up different versions of SDKs and device types for operating systems to test your app. In my opinion, you should physically test on a couple of the main devices that carry the latest spec and operating system version, and then use emulators to test the different variations.

Fragmented

Every year sees a new mobile operating system (OS), and because of this, there are a variety of operating systems for apps to run on. This broad range of OSs that are available is usually described as fragmented. Combined with the many devices available across each platform and their varying screen sizes, this means a lot of combinations that your app could possibly be used on.

Apple devices weren’t so bad for this in the beginning, although their variety has expanded since the original size was introduced. Android developers are the ones who need to make sure they perform a wide range of testing and lock down devices and OS versions that they do not want to serve with their apps so as to keep their testing to a manageable amount.

Gestures

With the introduction of touch-screen devices, gestures (e.g., single tap, double tap, swipe left or right, up or down) are now used just as much as digital keyboard buttons. Gestures help a user to interact more organically with a device than with digital keyboards or precisely selecting digital buttons.

Some apps like Tinder have become famous for their use of gestures within the app. These two gestures of swiping left or swiping right have become so synonymous with the reject or accept feature of Tinder that people only need to reference swipe left or swipe right in conversation for everyone to understand the reference.

Children as young as 1 year old are using tablets and smartphones better than their grandparents because gestures require no knowledge of language and are easy to learn.

As app developers, we need to keep in mind that using gestures instead of buttons to access functionality removes a high barrier to entry for users. And as gestures are easy to describe and learn, the user will be able to use your app faster and more effectively. This provides the user with a good user experience and will hopefully improve the number of users you retain after downloading the app.

Home Button

The home button (this could be physical or digital) is usually the only button on the front of smartphones. This button brings the user back to the first screen on the phone’s display. As an app developer, you need to factor in how your app will function if this button is pressed.

Icon

App icons are small unique images that are used to immediately identify your app within app stores and on devices.

They can look any way you want, but it’s usually a good idea to keep this icon within the same brand guidelines used in your app. It’s also good to depict something that represents the main function of your app so that users associate its use with your app icon.

Different stores have different guidelines for app icon graphics. Make sure you follow the correct guidelines for each store you submit to. This will ensure your release process isn’t delayed by having to redesign or recreate your app with different settings at the last moment.

JavaScript

JavaScript is a scripting language mainly used for web development. However, with the introduction of HTML5, JavaScript can be used to create complex apps with a web-based wrapper, so now web developers can create apps for mobile devices using the same skills used to create websites.

When you are thinking of developing your apps, you should consider which technology you want to use and which platforms you want to target. Using HTML5 can give you the benefits of developing using tools like Unity but without the same amount of complexity.

Keyboard

The keyboard is a versatile feature of smartphones. It can be changed to suit the language preferences of the user and even handle multiple languages being input at once (no need to switch between settings options).

The layout can also change to accommodate the user’s international keyboard preference.

Luckily, the user’s keyboard setting is usually something you don’t need to consider as an app developer. The keyboard will be displayed in the default language that you have set for your app.

Location

Apps use the location feature to identify where the user is. Facebook’s popular check-in feature uses the device’s location function to tag user posts with the location. Using location in conjunction with other features can provide more information to other users, and data to the app provider.

Magnetometer

Magnetometer allows your device to be aligned in relation to the Earth’s magnetic field. This means your phone will always be aware which way is North so the app can rotate to the correct position and orientation on digital maps.

Allowing your app to use the magnetometer requires a permission that you would need to allow when developing your app.

But, unless you’re making an app that requires this magnetometer functionality, like something that relies on geolocation or a compass app, this probably won’t be a permission that you regularly set up.

Notifications

There are different types of notifications that devices use: local and push.

Local notifications can be set up during the development phase of your app and are sent to the user depending on the type of notification, i.e., an event notification or a reminder notification. The times that these are sent will relate to the type of notification. Local notifications can usually be managed by users themselves within a settings area of the app.

Push notifications are sent after the app has been developed; they are live notifications to the user from the app provider. These usually give up-to-the-minute short pieces of information to draw the user back into the app. For example, these can be news updates from the company behind the app.

Orientation

Two main types of orientation exist for devices: portrait and landscape.

Portrait orientation is when the device is aligned vertically, as in a sheet of paper, and a landscape orientation is when the device is aligned horizontally.

As an app developer, you can choose to lock your app to the portrait orientation or the landscape orientation or allow the app components to change position depending on the way the user is holding it.

Permissions

When creating an app, you can only do so much before the time comes to add a great new feature. In order to do this, you need to enable the relevant permission on that device. This is usually a check box or line you need to add to a config file.

This alerts the user when they download the app that your app will require the use of additional tools like access to your contacts or access to your camera.

As users are becoming more proficient at using apps, they are more aware of access to their privacy and personal data. Some apps may not be accessing personal or private data, but the permissions that your app requires in order to function fully will be listed whenever someone tries to install your app. Showing users this message prior to installing the app gives them a choice and makes them aware of how the app is using their device’s content.

Depending on the permission (and whether it is integral to the main function of the app), you may find that the app cannot be downloaded unless you accept this message or that the app’s features are restricted until you accept these permissions. It’s all up to the user to decide.

QWERTY

QWERTY is the name for the original style of keyboard used in physical and digital devices. The name was formed from the first five letters on the left side of the keyboard.

Depending on the input fields within your app, you may want to restrict what type of keyboard is shown to the user at certain times. For instance, restricting users to the numerical keypad in a telephone number field may help you reduce user errors.

The decision to switch out this keyboard or lock a field to a particular one is a design decision that you should make when designing forms.

Rotation

As smartphones and tablets can be used in both portrait and landscape mode, the ability to rotate your app is also something you should consider when designing and developing your projects.

Yes, giving the user the option to interact with your app on different orientations makes it more accessible, but this will add to the design and testing time. You will need to ensure that your app functions and looks correct in both views and that it can move between both seamlessly at different points through the user journey.

To make this easier, you may decide to lock the rotation on certain screens, but this restriction may seem inconsistent to users if they can rotate it on some screens, and it’s not totally obvious why they can’t rotate it on others.

Always keep the user, your project time, and testing in mind when considering rotation.

Resolution

Resolution is the number of pixels that are able to fit on a device’s screen. As the years go on, we are introduced to mobile devices with even better screen resolutions, meaning that they can fit even more pixels in to give us a sharper, clearer and overall better picture from our screens.

Because of the fragmented landscape of mobile devices, when designing your app, it’s important to know the devices you target and the screen resolutions you will support. You will also need to make sure you test upon those. Differences in resolution can mean that objects positioned perfectly on the right hand side of your screen on one device may appear in the middle on others. Test for these differences, and develop solutions.

Status Bar

The status bar provides information to the user with icons. It can sit on or be hidden at the top of a device’s screen.

This bar shows users that there is something that an app wants you to be aware of and, obviously, the status of your device, e.g., whether the Wi-Fi is connected, whether you’re connected to a Bluetooth device, or whether you’re in airplane mode, all via icons.

If you use notifications within your app, think about an appropriate notification icon that fits with your app style so your user can identify it easily.

Touchscreen

Smartphones have been around since before the iPhone was launched. BlackBerry dominated this sector prior to 2007. These devices usually had a full-but-mini QWERTY keyboard, and the screen would take up the rest of the front. But the iPhone changed this. They showed that a full touchscreen was not only useful to users but also easier to engage with than tiny keys.

BlackBerry tried to launch their own range of phones with full-length touchscreens, but unfortunately for them, Apple already had their audience.

Touchscreen succeeded and was embraced quickly because of the low barrier to entry with gestures, great design, and onboarding process by Apple.

Because of this massive success in the change with how we interact with devices, more and more products like bank ATMs, POS systems in shops, etc., are utilizing touchscreen instead of physical buttons.

Although voice is now more widely used to communicate within apps on devices, using the touchscreen is still the primary source of input. This is because it’s easy for users of all ages to interact with. But it does depend of your audience’s level of experience with apps. So, as an app developer, you need to keep in mind that utilizing the touchscreen is great, but it needs to ensure that how you use it cannot be misinterpreted. For example, pressing and holding an object to interact with it isn’t something that you would naturally think of doing, while tapping is more intuitive.

USB Port

The USB port is always present on devices. It’s the primary way to charge phones, so it’ll always be a necessary feature until wireless charging takes off everywhere.

Micro USB was the dominant choice for Android devices (Apple always did their own thing), but now with the introduction of USB C, it seems that the world is waking up to the fact that we don’t want to have five different cables to charge five different devices.

USB C has been added to MacBooks and phones from both Apple and some Android phone manufacturers. So hopefully recharging will be a lot easier in the future.

So why’s this related to apps? Some apps can run directly on a USB device without the need to run on a device. And because of the portability of USB devices, apps can be device-agnostic and can run on pretty much most devices. A good example of when a USB app would be needed could be a support app for a company’s system administrator who’s upgrading all the computers and can’t do it remotely for whatever reason.

Some Android apps can be run from USB, but I highly doubt you’d have this flexibility with iOS apps.

Vibration

Vibration (also known as haptic feedback) was introduced to mobile phones very early. In phones as old as the Nokia 3210 and in games like Snake, vibration occurred when the phone rang, or you’d get haptic feedback when you caught your object in a game.

Haptic feedback is a good way to provide non-textual or visual feedback to a user to alert them to something or a change in state. It shouldn’t be used everywhere or excessively. Ensuring that haptic feedback isn’t being overused within your app should also be considered when testing your app.

Wi-Fi

Wi-Fi is a technology that many devices like laptops, computers, smartphones, tablets, etc. use to connect to the internet.

As an app developer, you need to make a decision whether your app will need the internet to function or not. You may want to serve your app content from a content delivery network via cloud computing solutions, so your app may always need to be connected. Or, you may want to use a cloud database to store the scores for your app.

These are acceptable reasons, but it’s always a good idea to build in functionality that allows your users to continue using your app when the internet is not available. So, when it comes back, you can send up or retrieve data again seamlessly without the user’s session being disrupted.

Xamarin

Xamarin is a cross-platform tool that allows developers to produce apps written in C# with a predominantly shared codebase across multiple platforms.

Using Xamarin tools allows you to create native Android, iOS, and Windows apps with native user interfaces. This gives developers the ability to create apps that the users will pick up quickly due to being presented with a UI that they are used to.

However, if you want your app to look consistent across the platforms, you can override the native rendering and implement custom renderer for individual components.

Yearly Releases

Every year, Apple and Google update their iOS and Android operating systems, so it’s important to be aware of the changes that these updates will bring and how they will affect your current apps in the stores and future apps.

For example, with the release of iOS 12, starting in March 2019, Apple is making it mandatory that all new apps and app updates for iPhone, including universal apps, will need to be built with the iOS 12 SDK to be able to support their new iPhone XS and iPhone XR, but especially their iPhone XS Max.

Make sure you get notified or keep up to date with these changes so your app project timescales won’t be negatively affected.

Zones (Time Zones)

(OK, I cheated on this one, but it was really hard to find something related to “Z”).

Time zones can be important if you have specific timed events that trigger notifications within your app.

Depending on where the user is, you may want this to trigger locally to them. Or, you may want this to trigger at the same time everywhere. You may want to consider where the majority of your audience resides so if you do choose the latter option, the majority of your users can enter your event at the same time.

This will need to be considered during design and development. Make sure you also think about a good way to test that this works!

Now You Know Your ABCs…

Apps have been around for 10 years now, but they are going to be around for a lot longer. It’s important to know the basics and background of what you’re working with so you know where you’re going.

If you’re new to app development or if you’re continuing to add to your app portfolio, I hope this has provided you some useful information so that you can build great app experiences.

When Resource Ids Are Not Recognised In A CS File

I’m using Xamarin Android for one of my current projects and (especially after my recent short break) sometimes I forget important lessons that could leave me confused and annoyed for ages.

Here’s an example of one of them:

Sometimes you need to create a new component in your axml file. You add an id and the rest of the parameters. Then you want to create the event that this button will call once clicked. So you go to a CS file, create a new variable to hold the resource and proceed to create a new event. Then the compiler catches up and you see a little red squiggly line under your resource id name 😩

Why Does This Happen?

The Resource Library is searched for the id of the new component when the code is pre-complied. The Resource Library is a file in the Android project listing all id’s of your components declared within your axml files. If the id of the component mentioned in the CS file doesn’t exist in the Resource Library, then this is highlighted as an error.

Resource Id Resolution

Comment out the use of the resource in the CS file, then do a rebuild of the project. After that, uncomment the reference of the resource in the CS file. Voila!

Reason

The new resource needs to be added into the Resource Dictionary before it’s used in other files. By commenting out it’s usage in the CS file, when the compiler checks for the resources, it won’t find it anywhere and will continue to add it the Resource Dictionary correctly without freaking out.

Coding is part banging your head against your desk, part shouting at your computer, but mostly (hopefully) part fun. It’s the fun that expires me and keeps me going when I hit those coding walls of despair. But I keep hope alive because I know I can get over it…eventually! If you code something everyday, you’ll start to hit these walls less often.

What You Can Learn From Contract Jobs

I’ve just completed a contract app project. And although I’ve completed and shipped projects to app stores previously, there are significant differences in the workflow and processes that make these types of jobs more complex.

For starters I’m working with other people so expectations to deliver are higher, working builds are essential and completing to the agreed deadline goes without saying.

Here are some of the things that I have learned over this recent contract project and what I’m planning on implementing in my development practices going forward to improve my skills and workflow.

The Contract (or Client Agreement)

After discussing ideas with external clients, contracts, client agreements and non-disclosure agreements usually come into play.

This is a standard part of working with any client as they want to ensure their work/idea is protected and you want to make sure the work agreed is scoped correctly, all deliverables are defined and clear to both sides, and if this keeps the client happy all the better.

I’m not a professional working in the legal sector so I must state that you should consult a legal professional in your area to make sure any contract you sign is acceptable.

While most standard contracts should be sufficient and simple, it’s important to make sure the contract covers all details. For example, you may want to make sure that the payment date is determined by the work being delivered and not when the project is being used or released.

Freelance Jumpstart had a great podcast episode for this topic. I would encourage you to watch or listen to this to make sure you include any additional points into the contract you sign.

Project Scope

The project scope should be laid out in detail before the work begins. I provide a quote to the client before hand detailing all features requests and the cost of each. So when it comes to the contract, you can reference this document or include it’s contents to the project scope section.

Handling Feature Creep

Feature creep may come from a client trying to build a better product, or it may be it you getting excited about the project and adding in lots of additional bells and whistles that weren’t even necessary (believe me we’ve all been there). Another way feature creep can occur is from reviews.

To ensure you stay on track with development, after every meeting, write a summary email with the meeting outcome. It’s important to detail here any changes to the project scope or deadlines that will be incurred due to these late feature requests. But the best thing to do is to state that although these would improve the project, they will also add additional time to the project length and may mean the project deadline will have to be extended.

Depending on the client and their deadline will depend on whether you add these changes in or not. Remember to get acceptance to deadline changes in writing.

Supporting Documentation

You may not have factored in writing these documents when doing your initial quote but be wary that these documents are essential for your client so they need to be done.

So if you add in a feature for e.g. analytics don’t forget to include a charge for the report creation into the cost.

Project Management

Whenever you begin a new project, it’s important to outline your development process so that both you and the client are in the same page going forward.

If your project is across a few months, I would recommend setting up weekly milestones in the form of calls, emails or in-person meetings with the client to show progress. State this in the development process mentioned above so that all parties know when to expect these.

Verify at the beginning of the project to find out if the client thinks this is too frequent and adjust accordingly. A weekly meeting will also help you as the developer to ensure progress early and often.

Release Candidate Build

A release candidate (RC) build is what I call the build that you have produced which you have implemented all of the features and are ready for user acceptance testing. This may not be but free, but it’s feature complete. Any bugs found in this build should be fixed and a new build created.

Put in a RC deadline into your calendar a week or two before the contract deadline. This will make sure you deliver on time and factor in working on bugs during the contract length.

Project Support

This is something you’ll have to negotiate with your client. After handover (or whenever the client begins using your project) is the time when they may need the most support. Be prepared to support the project for about two weeks after handover, but make sure you have this as an optional additional cost in the contract. If you’re planning to be away during this time, bring a machine to debug and build on in case unexpected bugs arise.

Images

When working with artists, request images in the correct sizes for each dpi folder. Or, if you’re willing to invest in some additional tools, you can also use mfractor’s Import Image Wizard feature.

For Android projects, these are the recommended sizes. For iOS projects, these are the recommended sizes.

Make sure that the images are also named in the correct naming convention for the platform or they’ll get rejected at compile or build time e.g. Android shouldn’t have uppercase characters or symbols other than underscores and can’t end in a number.

New Tools and Software

Working on a contract project instead of my own personal projects is a great way for me to stretch my own skills. For example, in this project the client had certain features that they wanted to implement, so this made me investigate using new tools and software that I maybe wouldn’t have chosen to use for my own projects. Doing this stretched my knowledge and has definitely helped me and my confidence grow.

The Good That Comes From Pushing Your Limits

I encourage everyone to work on a paid contract every now and again. It forces you to bring a higher level of professionalism to your work and when you’re at that level, you don’t want to go back to “anything will do to get this out”.

Lastly, I would advise you to try and accurately estimate the work you need to spend on implementing your features. If you find that a feature has taken half an hour to implement rather than the two that you estimated, move onto the next task and do something daily. Doing this early in the project will lead to more productivity and hopefully no crunch at the end.

Never crunch!

This post was exported in one click from Google Docs into WordPress with Wordable.

Get Up And Code Something Everyday

Being able to code something everyday is a great way to improving your development skills. Just like Jennifer Dewalt who built 180 websites in 180 days, you will slowly notice your skills improving. Things that you may have struggled with to begin with becoming easier.

The journey to building great development skills doesn’t happen overnight. I have to always remind myself of this fact. It takes time, lots and lots of time! Doing something small and short everyday helps you keep up your momentum, moves you forward little by little and keeps you motivated.

Experiment 1: Asset Store Graphics Package

From now, I’m going to be undertaking conscious and a more structured approach to my appreneur journey. Instead of just building small apps that I’d like to see on the app stores, I have decided to also target the supporting connected services of app development to broaden my revenues streams and increase my skill set from just programming.

Experiment 1

I’ve found that the graphics package that I created is selling better than my project template on the Unity Asset store. Graphics packages are easier and faster to produce rather than full templates or code samples. And buyers can easily see what they will get for their money.

In this first experiment, I’m going to create a set of my own menu icons. Menu icons are something that I use across all my app projects, so by creating a set of them to reuse in every app, it will mean more consistency across my apps for users. It will also mean that I can tidy my Dropbox folder of icons so only use a few variations.

Another reason why I choose to create graphics is that the skills I gain from this experiment will be create a good base to build upon and will be useful for years to come.

Goal

My objectives with this experiment are to:

  • Improve my design skills from MVP to mid range

This will allow me to become more self sufficient at developing apps up to a higher graphical level.

  • Create at least one set of menu icons suitable for sale in the Unity Asset Store.

This will give me another product that I can begin to sell to hopefully increase my revenue from the Asset Store.

Contents of Icons Package

The menu icons I’ve identified that I consistently use are listed below. So this (at a minimum) will be my base set of menu icons.

  • Button background variations – slightly rounded corners, rounded corners, square corners
  • Menu
  • Pause
  • Play
  • Rewind
  • Fast Forward
  • Sound playing
  • Sound muted
  • No sound
  • Arrow left
  • Arrow right
  • Arrow up
  • Arrow down
  • Reset
  • Skip
  • No internet
  • Saving
  • Save
  • Load
  • Unable to save
  • Settings
  • Cancel
  • Close
  • Back

Project Length and Deadlines

I’ll be doing this experiment in between my contract work and my other project, but I’m hoping the progress will be good.

As it’s July, I thought that a suitable length of time for this experiment would be until the end of the October. I want to get these icons completed by the end of September and into the Asset Store by the end of October. It may sound like a long time, but I’m going on holiday in August and currently wrapping up a client project. This project could lead to a second stage which would be completed by December so I didn’t want this experiment and that project to overlap too much especially during the later stages of the project. Overall, I think this is realistic time frame.

Follow Me To Learn More

I’ll probably post about the results of this experiment on the blog at certain points and then do a post about my results of this experiment. So, if you’d like to hear more about my progress within this experiment and other projects I’m working on, I’ll be sharing skills learned and assets created to my mailing list every couple of weeks so please sign up to get updated.

Career Mentors (Bye Jay)

Today my manager Jay is leaving. It was a massive shock when I found out. As he’s the CTO I had two thoughts:

  1. “Oh no, I’m sad now”
  2. “Is the company in trouble?”

So in fact, he’s making the decision to go purely because he wants a new challenge which is completely understandable and I wish him the best of luck.

He has been the best manager I have had so far because he’s been supportive, encouraging, and an ear when I need to moan (which can happen often as I am very picky particular dedicated to delivering a great product). He also doesn’t just tell me things I want to hear (which is pretty rare in people). I get honest answers and opinions.

Being a woman in tech, I didn’t have many people to look up to in order to steer me in the right direction, getting me to where I am now. I have done it all by myself (which makes me proud now that I think about it) but it’s been exhausting.

I haven’t had someone else to give me their wisdom which would’ve undoubtedly meant that I probably would’ve made less mistakes along the way. But from the beginning Jay has given advice, let me feel like I can research everything that will help improve the team and the area that I work in for the company, has given me autonomy, let me attend the events that I want (through which I have met some great people), sends me Twitter links to awesome women in tech (like @TheAmyCode) for further encouragement, and in general has made me feel more confident about being in this role and that I deserve this role because I am awesome.

Find A Career Mentor

It’s important to find people like this to guide you through your career because no matter whether you’re male or female, careers are hard and a little guidance goes a long long way.

If you do find these people, make sure that it’s not just a one-sided relationship. Make sure that there’s something that you can give them too. Whether it’s small things like being self-sufficient so that they don’t need to worry about you or giving back something tangible that could help make their lives easier or better.

So, bye Jay. See you soon, it’s been great working with you and remember BBQ!

 

Moving to Containers

It seems that containers are the new technology within IT that everyone is trying to incorporate into their infrastructure. And why? Containers not only benefit those in DevOps, but have positive implications for all teams involved in product delivery.

At Immerse, we’ve recently moved our infrastructure to a containerised solution. It’s early days to analyse the impact that this has had on our development teams, but I thought it would be a good opportunity to deepen my understanding of the this technology.

What Are Containers?

Containers give us the ability to store a number of different systems virtually within the same location. This means that if one environment needs a website front-end, server and database in order to function, all of these can be stored within the same place.

What sort of systems can be run within containers? Well, that’s where container images come in.

What Are Images?

A container image is a stand-alone, executable package of a software that has everything needed to run it including code, runtime, system tools, system libraries, and settings.

An image is required in order to build a container, otherwise it will be empty when created.

So where did all this new tech come from then? It seems like it’s come out of nowhere but spread fast (kinda like Bitcoin right?). Well, it all started by a small company now called Docker Inc. They created the system that containers run on, Docker.

What is Docker?

Docker is a computer program that allows you to perform operating-system-level virtualization known as containerization. This is the creation of containers.

Docker allows independent containers to run within a single Linux instance. This reduces the overhead of starting and maintaining virtual machines (VMs).

Since Docker began, there are other tools than have been developed that can perform containerization.

The World Before Containers

Before we used containers, there were virtual machines (VMs). VMs remove the need for physical hardware and allows one server to be turned into multiple servers. App of this is possible because of a hypervisor.

A hypervisor (also considered a VM monitor), is software that creates and runs VMs. It is the reason why you can run many VMs on a single machine. Each VM will have a full copy of the required operating system, one or more applications and the needed binaries and libraries. All of this can take up tens of gigabytes of space!

Some companies have made the switch to containers from VMs because:

  1. VMs can also be slow to boot, while you can spin up a container within a few minutes providing you have the right image. And if the don’t, that usually only takes a few minutes to obtain.
  2. You can pack a lot more of your companies applications into a single physical server using containers than a what you can fit in a VM.
  3. VMs take up a lot of system resources as they not only just run a full copy of an operating system, but a virtual copy of all the hardware that the operating system needs to run. All that a container needs is enough of an operating system, supporting programs and libraries, and system resources to run a specific program.
  4. With containers you can create a portable, consistent operating environment for development, testing, and deployment.

So How Do You Manage Containers?

Container Orchestration are frameworks that are used to integrate and manage containers. These are not necessary for everyone using containers. Usually enterprise level organisations are more likely to use orchestration tools as they manage a large range of containers and their images. Examples of these tools are Kubernetes, ECS and Ansible.

These tools help to simplify container management from the initial deployment to managing multiple containers, scaling for load, availability, or networking.

The Benefits and Drawbacks

Like any new piece of technology or tool, containers too have their own list of benefits and drawbacks that mean you choose to either integrate them into your development pipeline or you don’t. So, what do containers offer?

Benefits

  • The ability to spin up whole environments consisting of all the systems you need within minutes.
  • The ability to change the configuration and deploy those changes quickly.
  • Containers allow all users of the system to be self contained. This mean that rogue developers who develop new features, don’t run tests locally, push to the test environment, then leave to go home only for QA to find that test is broken is no longer a daily issue (wow, that sounded like a rant!).
  • Features can be tested in isolation easily.
  • Testers can be in control of checking out and pushing features to the test environment.
  • Differences between environments is no longer an issue because they’re all spun up from the same set of stable images

Drawbacks

  • Initially, there maybe some complexity to setting up containers.
  • There are some security issues that you med to be aware of when using containers. For example, if a user or application has superuser privileges within the container, the underlying operating system could, in theory, be cracked.
  • It’s time intensive to set up decent security measures for containers. There’s no default, out if the box solution yet
  • Everyone is making container images and it could be easy to download something malicious into your system.
  • Breaking deployments into more functional discrete parts is smart, but that means we have more parts to manage. There’s an inflection point between separation of concerns and container sprawl!
  • Containers tend to lock you into a particular operating system version

Are containers the future of development?

It seems because of the fast adoption of containers that they may eventually replace VMs once their issues have been overcome. And because it is a new technology, there will be drawbacks at this early stage so don’t let these deter you from experimenting with the tech yourself on your own projects.

However, technology has changed extremely fast over the last 30 years, so it may be that containers are superseded by a new emerging technology that solves the drawbacks of containers and gives us a while load of other benefits too.

For more information of containers especially if you’re learning the basics, please check out the Docker videos by Nigel Poulton on Pluralsight. I found these videos extremely helpful in delivering information and background about a brand new technology. The concepts were also broken down into easy to understand topics which is perfect for beginners. After watching them, I was able to understand a lot more and felt more confident when speaking to the DevOps at Immerse about how they had implemented container and why they made the decisions they did.

What’s your experience with containers? Do you love them? Are they growing on you? Or, have you not yet made the leap into using them? Whatever your experience, I hope this article has given you a better insight into the background of containers.

For more information about containers, please feel free to view the references I used:

This post was exported in one click from Google Docs into WordPress with Wordable.

Rebasing from Master onto your local branch

 

Now that my QA team are adding to the test coverage by writing integration tests directly into the project code base, it’s finally time that I start to embrace rebasing (I sort of feel that lightning should crack when you read rebasing)!

As I survive with the basics of Git and because Irina and I only usually submit to our own repos, apart from branching and merging back to master, there’s not much activity going on. But once you work on a repo where at least two people are active on it, merging their code into master and creating branches weekly, your local changes can fall behind quite quickly. This is where rebasing comes in.

Rebasing essentially rewinds back your branch to when you created it from master (if that’s where you branched from) and applies all the commits that have happened from master branch to your own. If there are conflicts or differences between the commits to the master branch and yours, you can either:

fix them at each commit, then you

[sourcecode language=”css”]git rebase –continue[/sourcecode]

, or you can accept the changes on the other branch and

[sourcecode language=”css”]git rebase –skip[/sourcecode]

The concept is quite clear to me (now), but what I struggled with was doing this all on the commandline. I know I could use a tool like Source Tree to do all the heavy lifting for me, but in fact, despite me being quite a visual person, I like using the commandline for Git. So I vowed that this will be the time to learn and to do it more often so that it’s solidified in my brain.

So after being walked through the process, I learned that these are the steps that you need in order to rebase from master on to your own branch.

So these are the steps, pretty simple and after a couple of times, I reckon I’ll be able to do this from memory…providing the conflicts are few and far between!

[sourcecode language=”css”]

git checkout master
git pull
git checkout MyBranchName
git rebase master
git rebase –continue (until you fix the conflicts) or git rebase –skip (to skip these changes)
git pull
git push
git status

[/sourcecode]

The steps here are what I found works, but if you spot anything wrong, don’t be afraid to let me know.

9 Steps To Approach A Development Task

Here’s my next post which appeared first on Simple Programmer.

As a new developer, I’m trying to focus on producing the best work the least amount of time. This is obviously going to take me longer than someone who has worked for a number of years in development and gained lots of experience. But I believe that establishing the right process now may save me a lot of time in the future.

Now, I want to recommend a good development method, especially for beginners. I also want to introduce you to steps you should work through before you even start writing any code.

The Basics of Scrum

In my team, we work using the Agile methodology Scrum. For those that aren’t familiar with the process, here’s a brief explanation.

Scrum is a process of working to create a product that is iteratively developed by breaking down all new requests for big features (known as Epics) into bite-sized chunks called Work Items.

Each project usually has a team of five to nine people (the optimum being seven), who work on an agreed set of items for a set length of time known as a sprint.

Our team sprints usually last two weeks, so every two weeks we have a new set of items divided up between the team.

You Have Your Item, Now Where Do You Begin?

What I found difficult to know when I first began was where to begin my work item, or in other words, what to work on first. Once I’d worked out the most time efficient order in which to complete the tasks, I went about tackling number one on the list.

Moving from testing to development, I didn’t have much experience with unit tests or Test Driven Development (TDD). While I knew it was a good idea to use TDD and write unit tests, it wasn’t imparted upon me to put this knowledge into practice. So, given the option as a beginner, I generally made the mistake of jumping into writing the code first.

The Basics of Unit Testing and TDD

Although it’s not expected, our team does try to use TDD. In this system, you write out unit tests to see whether your code produces the correct result for the business logic you’re trying to match.

After you have finished development, this yields a quick way to check and see if any issues have arisen within your code, even years later when new functionality is added.

New functionality means new tests should be written. Eventually, you build up a solid set of tests to fully cover the code you have written, which is known as code coverage.

The tests that you write are usually located in a separate test project alongside your project within your solution, but this is all dependent upon how your team structures your code base.

Managing Time Constraints Using TDD

When I’ve used TDD, I’ve found that coding using this method is great for someone new to development. It forces you to break your code down into small, testable chunks to achieve one purpose. This makes you think more about how you are going to structure your code before you write it.

However, TDD is very hard to stick to when you’re under time constraints (which is almost always). I did want to try and stick to this technique, but I kept coming up against this issue of time.

I think using TDD was a good step in the right direction for learning how to approach a development task, but I felt some bits were missing. It already assumes you have total knowledge with what you’re doing, and that might not be case. You may even find that once you sit down and read the item yourself, you have deeper questions that weren’t covered before. Because of this, I decided to seek advice from someone older and wiser.

Early on into my transition from a tester to a developer, I asked my manager the best way to approach a development task. At the time, he’d been developing for about ten years across different technologies and software, so he’s a pretty good source of information.

Here’s the advice I got in 9 simple steps.

1. What’s your goal?

To establish your goal, you need to do three things:

Clearly understand your work item
Figure out what the business requires from this change
Grasp the business value of this change

If you’re not sure about any of these things, talk to the appropriate people to gain this knowledge before attempting any coding.

2. Discuss the best way to accomplish your goal with others

Consult with other, more experienced minds on your team to help you get to your solution quickly. Again, the aim here is to use your time efficiently.

By all means, try and overcome challenges yourself, but be mindful of the time you spend on it. You should not and do not need to shoulder all the work yourself. No matter what level of experience you have, don’t be afraid to ask for help or turn to the all-knowing Google.

3. Break down your goal into tasks and objectives

Smaller chunks are easier to digest; it’s just logical. Before you begin, think about your goal, what you need to do, and then tackle each task one step at a time.

Making lists or simply brainstorming what you think is involved is a good way to clearly see the steps you need to take. If you order these steps, it will also help you identify a logical order to proceed. Hopefully, this will ensure less jumping back and forth within code.

4. Look for similar existing unit tests and run them

Think about the current functionality that exists in the product you’re enhancing.

Is there anything similar that you can step through and debug to help you make your task easier? If you find any methods like this, try and find tests that execute these methods to check if you can extend them to fulfil your new task.

5. Write your new test

If all else fails, write a brand new test from scratch, but start by writing a test and not by writing the code for your solution. You start by writing the test because you know the outcome you want to achieve. You want to do X to achieve Y.

You will also have some idea of where your new code will sit within the project. Writing an empty method here for your test to run over will provide you something to build upon and expand in order to make your test pass. Lastly, writing your test now will save you time later.

6. Solve the task with the minimum amount of code

Try and use the least amount of code to write a solution for your task in order to fulfil it. Don’t worry about efficiency yet –– just get it done.

You will be tempted to try and write code perfectly to ensure the least amount of bugs, the greatest performance gains, and to show off your awesome coding skills. However, you need to keep in mind that doing all this may take you longer to do than solving the initial problem, especially if the task is small,. You need to keep in mind that you may be over-engineering a solution or trying to future-proof against scenarios that may never happen. Be efficient with the time you have now.

7. Make your test pass…

Run the test over your small chunk of new code. If it passes, great. If it doesn’t pass and the reason isn’t obvious—for example, the condition of the assert wasn’t met—you need to debug the code.

Go through each line, inspecting the value of each variable, property, and return statement.

Once you’ve found the culprit causing the issue, fix it and ensure that your test passes and fulfills its task.

8. …Then refactor your code

Now that your test has passed, you can extend your solution to become more efficient. Don’t forget that for every new method you may need a new test or two or more. This will depend on the number of ways that block of code can be exited. For example, you could go through the block of code where everything functions as normal and you get the result you expect, like a list of objects. But, there may also be a case where you could go through the same block of code and an error occurs which gives you a list of the same objects but they’re empty. Other ways to leave the code could be a number of different types of exceptions. These all would need different tests.

9. Work back through step 7 – 9

Repeat steps 7 through 9 to ensure that the changes you’ve made in your code don’t make the test fail. If it does fail, debug the test to find out why.

Feel free to add in as many assertions to verify the outcome of your tests are correct and reliable at any stage.

And That’s It! Easy, Right?

Well, no. Actually, it takes quite a lot of discipline to avoid jumping straight into coding the solution, especially when you’re a junior developer.

However, if you want to try and take small steps towards using TDD, you could try an alternative approach. If you write tests as you go along, i.e. after every method you create, you will save yourself time after the development of your features.

10 Tips To Start Off Well In A Junior Dev Role

Here’s my next post which appeared first on Simple Programmer..

As I look back on my first full year of working as a developer, I have realised a number of things that are essential to this position.

Daily, a developer needs to think mostly like a developer, but partly like a business analyst to get the reason why the business wants the new feature. You need to think partly like a product owner to understand its value of this in the team’s roadmap, and partly like a tester to defensively code around the ways they will think of breaking your beautiful new feature by anticipating users’ behaviour. That’s before you consider all the tech skills developers need to accomplish fulfilling the tasks these different ways of thinking will bring.

These different ways of thinking and the abundance of skills are things that I didn’t consider when deciding to switch careers into development. Taking all this into consideration, I thought back over my first year and came up with a short list of tips that I think will help anyone entering as a junior developer in any industry. If you implement any of these tips below, I am positive that your first steps into a development career will be a lot less daunting, a lot more productive, and get you off to a great start.

Embrace debugging and improve your debugging skills

You will always need to debug no matter what level you get to. Most of a developer’s job is reading code, figuring out how and why things have been made the way they have, and fixing bugs. But it can take you a longer time than most developers if you’re not as experienced at reading code. And even if you are, trying to navigate archaic code or “smelly”, “unclean” code isn’t a task you enjoy. Because if you’re a good developer with a conscience, you know that you’ll have to fix the issues in the code that you’ve found on top of your original task.

Practice reading code

The best way I’ve found to improve is to read code as often as possible. Just like any language, the more you read and write it, the more you’ll improve.

Always be asking “How does this work?”

Delve deep into how something works the way it does. For extra credit, learn the reasons behind the technical methods that were chosen to fulfill this feature.

Diving deep

Walk through the code and see if you can understand why it works the way it does. To understand what technical techniques were used, speak to any long-standing members of your team that would know why they made those technical decisions. It may be that the methods they used are now outdated and you can suggest newer techniques that will save time, save money, or improve performance and ultimately make your company more money. This is always a big win in your favour.

Understand the value of your task

There’s no point in spending time implementing a new feature if you don’t understand why you’re doing it, how it’ll be used, what value it’ll provide the end user, and its impact on the business itself.

Look at the bigger picture

Make sure you talk this through with your line manager about the larger value of the product you’re working on. It’s their job to ensure you get all the help you need in order to produce the best results.

This is usually discussed before you even start developing. But if you’re unclear, make sure you ask why you’re doing what you’re doing. You could have a new way to approach the task that hasn’t been thought of which would deliver more value.

Find what you enjoy and become an expert

Let’s be honest. During the first year (or maybe longer) of your development career, you’ll feel stupid.

The sheer amount of technology that you’re supposed to be able to use competently will overwhelm you. What will keep you optimistic, even on those dark days where you feel everything is breaking and you’re powerless to stop it, is finding something you enjoy.

When you enjoy something, it doesn’t matter how inexperienced you are in the topic, you’re just learning, so it’s all fun and games. You don’t expect to know everything, but you’ve got the confidence that you’ll get there eventually.

Become the expert in this topic and make sure you share your learnings with the team.

Explore your interests

Keep a log of the different skills that you use daily. Make a short list of the ones that you enjoy, pick one and deep dive into it.

Picking a skill that you use daily means that it’ll continuously be useful to you and your team. Whereas, if you pick a tool that you’ve only used once or twice i.e. a really cool bit of new tech to solve an edge case business problem, it may be fun, but there might not be any long-term use. So although diving deep into a specific skill is a good idea, make sure that you gain a return in the long term for the time you invest.

And picking one means you won’t spread yourself thin. You can focus on building that one skill up so that you are confident using it.

Keep a log of your activities

I think I learned this skill from one of John’s YouTube videos. Keeping a log of your activities helps you to recall what you’ve done and learned in your role. It also gives your manager an insight into your daily activities if you’re not in regular contact.

The format of this log is up to you but remember, this log should not take time away from your actual role.

Create a template that’s quick to fill in but extracts the important information for you or your manager to peruse. I would also advise that you send these logs to your manager on a weekly basis as opposed to daily.

How I do this?

I experimented with completing daily logs then compiling these into a weekly report for my manager. But in the end, this took way too much of my time. So I ended up just completing a weekly log and I email this to my manager every week.

In my template I include:

  • My feelings for the day
  • Weekly goal
  • Daily tasks
  • General daily summary
  • Numbers for work items
  • Anything unexpected
  • Anything I’ve watched, read, or attended that improves the skills I use in my role
  • My next week’s goal
  • Lessons learned

Find out what skill or role your team lacks then throw yourself into it

Every team has their own strengths and weaknesses. Your team is no different.

If you’ve created a shortlist of topics you enjoy or, if you’ve been compiling your list of daily skills in your weekly report, you may want to figure out what skill your team is weakest on.

How to do this?

After identifying this list, you will be able to see if the skills that you most enjoy cross with a skill that the team needs. If so, great! You can kill two birds with one stone, finding something that you enjoy and provide the team with valuable knowledge in an area.

If not, then pick the skill that you believe will give the team the most value.

Try and pick a resource or medium that you learn from easily so that the information can be absorbed quickly.

Keep a log of anything you do above and beyond your job in a ready to view format

In every permanent, big company role that I’ve had, there is always a process in place to review performance of employees.

But, when you’re sitting in front of your desk looking at a document asking you what you did six months ago to contribute to the organisation, it’s not surprising if your mind goes blank.

Everyone finds recalling information like this challenging. Sometimes people can’t remember what they did the day before, let alone six months ago!

Compile your list in a single file

I’ve tried a few different ways of keeping track of my extra activities. I first tried keeping a list with pen and paper noting down the task I did and the date. I found that at this stage, you don’t need to mention what the outcome was, as you’re just noting it down so you don’t forget all of your examples.

But, this list suddenly became quite long and random bits of paper tend to get lost or deteriorate over time. I needed a more durable and easy to edit solution. Enter Excel.

My second solution was to use Excel and use it in the same war as the pen and paper. But I found that maintaining the dates and accounting for ongoing tasks wasn’t so simple in this format. So, I searched the internet and found this free timeline software. It’s really simple to use, and exports to PDF.

I’m still using this piece of software now (although I’d love a Mac version).

So, what should you track?

Note down everything you do inside and outside of work that either directly contributes to your role or strengthens any other skills you’re interested in.

If you’re working with a backlog, you may find setting this up is a bit tedious, but have patience. Once it’s done, it’s done and very simple to update.

As a junior, you may feel that you’re constantly learning and never gaining knowledge. But this will paint you a very different picture. After six months, looking back on your timeline will make you feel really awesome. Your confidence in your abilities will soar because the timeline clearly shows you exactly what you have achieved.

Make time to train yourself everyday

It’s important that you keep up your skills in a software development role, because the technology in this field is ever-changing. So don’t wait to be offered training by your manager –– seek it it out yourself.

Finding time even on busy days

Carving out time to learn will be another challenge. It takes a lot of discipline to stick to a training session every day. You need to make sure that you don’t take on too much day-to-day work so that you’ll have to skip a session. The danger of this is that once you skip one session, you’ll be more likely to skip another.

To combat this, schedule this time into your calendar and set yourself as busy. This will deter anyone from contacting you during this time, remind you that your session daily will be commencing soon so you can prepare, and get you into the routine of training yourself regularly.

What do you train on if you don’t have a focus?

If you don’t know where you should start, you can either focus on:

  • skills that your team needs, or
  • improving your weaknesses

There are many resources online that you can use to train yourself. These range from free, online courses to paid and subscription courses like Pluralsight, Udemy, and Coursera.

Like everything you want to improve, you should do this everyday. Even if you do one coding challenge, read one page of a chapter of a book, or watch one video that will improve the way you work, it all adds up in the end.

Share your challenges and how you came to the solution

This is invaluable to show how you learn and solve problems. Try and share solutions with others in the same position as you, with the same problem. Sometimes learning from someone at the same level as you is far easier than learning from a senior.

How do you do this?

Try and keep this in an easy to search format, so if you find the problem you solved months ago reoccurs, you’ll be able to save time searching Google for the solution.

Blogs are the easiest way to store this information (and one of the things John recommends every programmer has), because they are easily accessible by everyone.

Make sure your posts are properly tagged and are SEO optimised. Doing this in a public medium does mean you’re more vulnerable to negative feedback but it also publicly builds up your authority and shows your growth to the community. So ignore the haters and keep blogging.

Find a mentor

Everyone knows that you learn best from making mistakes, but it can be more beneficial sometimes to bypass your mistakes altogether.

If someone else has already spent time making the same mistakes, has learned the lessons, and is willing to share their findings, wouldn’t you want to skip the mistakes and go straight to the lessons learned? This is exactly how a mentor can help you.

Among other important things like guiding you in your career, you can use mentors by listening to their experiences and what they’ve learned.

How you should do this?

A mentor can be someone within your team or outside of it. To be honest, they don’t need to be within the same field you work in. They just need to have gained the skills that you want to acquire or level you want to reach.

In some companies, pairing juniors with someone more experienced is a structured programme, so take advantage of this if you think you’ll benefit.

However, for many, finding a mentor can be tough.

Being a mentor can require a lot of time to deliver the best value you can to your mentee and sadly, some people just haven’t got the time. So if you are one of the lucky few who get a mentor, make sure you’re clear on what each of you expect, the time you can both put in, when you’ll meet, how often and what you’ll discuss in each session to ensure neither of you waste your time.

If there’s nothing formal set up in your company, ask your manager if they can arrange something. If you’re not able to find anyone within your company, there are a few sites that match mentors with mentees, like Mentorsme.

If you do manage to find a mentor, don’t accept someone without first asking them about themselves, their skills, experience and their time restrictions. Also keep in mind that your mentor should be someone you get on with as you’ll be spending your precious extra time with them.

So there you have it

I feel that recording your progress, sharing your newly found knowledge, knowing where you’re going, and getting the guidance by more experienced minds is crucial to starting off well as a developer.

Being able to reflect over your accomplishments throughout your early days as a developer is crucial in building your confidence. It may also give you an indication of which path to specialise in. But, you can’t do that without keeping logs and recording your progress. Recognise that at the very least this task will help you identify your own achievements and be a physical reminder that you have grown in your field.

I’d love to know what you think. Which steps do you think are more important? Have I missed something that you’ve found was integral to your progression and growth? If so, feel free to leave a comment or message me so we can discuss our junior developer challenges and hopefully overcome them together.