If a younger version of myself were transported to 2024, I know he’d be asking this question. I can only imagine the anxiety that young software engineers must be feeling about it. There are countless Reddit and Hacker News threads for aspiring developers discussing the topic.

AI is a tool

Will Software Engineer even be a job title in 5 years? 10 years? It shouldn’t be a surprise that people are asking this question in the context of the proliferation of generative AI. I believe that there will always be a need for at least some human oversight when it comes to AI code generation. The demand for talented engineers who exude creativity will always be there.

2025 will mark the 10-year anniversary of me starting Computer Science at university. When I first set foot in the markedly dark Kilburn building (there’s NO natural light — Manchester PLEASE install some windows!) I felt SO out of my depth. I didn’t even know what an ‘if’ statement was. A ‘variable’, also no idea. When it came to coding assignments, Google and StackOverflow were my best friends. Is generative AI used in this way so different? Possibly not, but there could be a risk of overreliance when it comes to learning with it.

A survey conducted by Gergely Orosz and Elin Nilsson explores this topic asking seasoned engineers. Some engineers are extremely bullish on the future of AI, most less so — one response states “Copilot is like pair programming with a junior programmer. I use it to do the rote work of filling in the details of my larger design”. Admittedly, I agree with this statement and think there is a short-term temptation for corporations to hire fewer junior developers. This is short-sighted. Junior engineers are so much more valuable than the code they write — their value lies in the fresh perspectives they bring, the candid questions they ask and the fact that you can mould them into the more senior engineers (and team members) that you eventually want to have.

Where is the creativity?

Large Language Models (LLMs) lack creativity, (at this moment) they can only output something they’ve seen before (i.e the dataset that they’ve been trained on). If their original data set is garbage then that’s all you’re going to get in the output. They can’t think; they just predict the next character (or phrase). This means they can’t solve novel problems that engineers encounter all the time, especially in abstraction and system design.

It’s easy to see where you can get stuck in a LLM training loop (e.g Garbage in, Garbage out. You may think “Why not just train on data before (say) 2022?”, to which I ask: “What happens when we run out of data??”. I think this is already our reality, and I think humans will be required to fix the mess.

As I previously mentioned, I am actually personally worried about the over-reliance from junior engineers (and to be honest, anyone) for learning with AI. Could we reach a point where juniors never learn the “correct” way to do something? I’m not sure what will happen in this case, but the goals of the big AI companies are to make sure their models are not trained on rubbish.

The fact that LLMs need to be trained means that they struggle with novel technologies, and they will often hallucinate but with confidence which makes it all the more dangerous. I don’t see a way around this problem currently, however, I’m sure a lot of people who are cleverer than me are working on it. At a recent developer meetup I attended, we were discussing whether we’ve witnessed the last new (human) written programming language. Maybe we have? That is a scary thought.

It’s our duty to fix things

Have you heard of the dead internet theory? It’s the theory that most of the activity on the internet is conducted by bots and most of the content is autogenerated by tools like LLMs. I alluded to it earlier in this blog post. A recent study (June 2024) conducted by researchers at AWS was literally called “A Shocking Amount of the Web is Machine Translated: Insights from Multi-Way Parallelism”. I’m not usually someone who buys into conspiracy theories; however, it seems we’ve passed the tipping point where the majority of content on the web is machine-generated. This is a great shame. I believe that LLMs lack creativity and I think it’s our duty to fix the internet.

Front and centre of this battle will be (are!) software engineers. Software engineers built the internet and they are continuing to build it. They’re building meaningful projects and equally they’re building silly stuff that means nothing! That truly is the beauty of the internet.

Here are some makers who are building stuff to make the internet feel alive again:

• Nolen (@itseieio on X, formerly Twitter) built One Million Checkboxes — a fun little website that is literally one million checkboxes, the twist being it was a multiplayer experience. A box you check gets checked for everyone else. He was expecting a handful of people to try it but a tweet of his went viral, and in the end over 650 MILLION checkboxes were checked! Insane. He’s written extensively about his experience building the site, including an absolutely charming story about finding secret messages and communities within the checkboxes. This is the best way to learn software engineering by the way — throw goofy projects out there as soon as you can, if people use them, fix the issues and scalability etc. I would wager that Nolen wouldn’t have even launched OMCB if he thought about scalability beforehand, this way he’s probably learned as much as years of experience of a 9 to 5 SE job would teach you.
• Spu7Nix’s “How I made a 3D Level in a 2D Game” is another example of how ridiculous passion projects really resonate with the internet. He spent many months building a 3D level in geometry dash (a 2D platformer) using clever programming tricks. It’s hard to explain in writing but, I would highly recommend watching the video if you have a spare 20 minutes.
• Jacob Bartlett’s “My Toddler Loves Planes, So I Built Her A Radar” is possibly the sweetest story in the Software Engineering space I’ve read. You can build such meaningful experiences for your loved ones if you learn software engineering. LLMs will never replace the creativity of humans.

I won’t detail every example I find inspiring but here are a couple others -Jacob Binnie (building a startup from scratch after having been fired and documenting it on YouTube), ThinMatrix (talented game developer making his games in his own game engine),

Partially inspired by the above I built my now fiancée an app to propose to her. It was a treasure hunt around London, visiting places that mean a lot to us, coupled with clue reveals from games inspired by the New York Times style games and Geoguessr. I’m so glad I built this little app. The day I proposed is one that we’re going to remember for the rest of our lives. Oh, she said yes by the way! Stay tuned, I’ll tell the story in more detail very soon.

All of this to say: Build stupid things. Build meaningful things. Build things no one uses. Build things for yourself. Build things to change the world. Join the fight!

Admittedly, this article only stands as true in my mind as of writing this in September 2024. This space moves quickly and things can change, however, I do believe Software Engineers are and always will be artists. We are the architects of the silly internet, and you can be too. I think that is beautiful.

We are in the midst of the industrial revolution for Artificial Intelligence. The proliferation of AI services for consumers is something to behold. Google, in their recent announcement for Bard, makes reference to a study that postulates “the scale of the largest AI computations is doubling every six months far outpacing Moore’s Law”. This level of progress is staggering and looks to only increase. In this blog we’re going to take a look at how some of these tools work, why Google needs to respond to OpenAI and Microsoft and what this means for the sector.

What are Large Language Models, and how do they work?

Large Language Models (LLMs) are models that are trained on billions of points of data in a particular language and attempt to predict the next word/sentence. ChatGPT is an example of a LLM. ChatGPT was trained using human feedback, you get it to generate multiple responses given a prompt, you show them to humans and the humans select the response they like the most. Instead of using this feedback directly, it’s used to train another model which tries to predict which future response a human would like more, this is then used as the reward function to train the LLM. The reward model allows training to scale as it imitates humans and thus does not require thousands of humans to train the LLM. The process is repeated, humans rank the new responses, that new information is used for training the reward model, etc. until the LLM is sufficiently trained in the task that you require.

There’s a flaw with this training system, the LLM is being trained on what response humans prefer rather than the factual information. ChatGPT is perhaps more likely to have a “stab” at predicting something that it doesn’t know rather than saying it doesn’t know as that’ll score more highly with the reward algorithm (and humans). I’m sure you’ve seen examples of where ChatGPT made up studies or where an obvious fact was wrong, sometimes quite humorously, this is the flaw in action. Could a solution to this give the model real-time access to information — Wikipedia for example (I can hear teachers saying “never quote Wikipedia”), cleverer people than me are addressing issues like this.

Why did Google need to respond to OpenAI?

Before the acquisition of OpenAI by Microsoft, Bing (Microsoft’s search engine) represented just 9% of all global web searches. Now, OpenAI (Microsoft by proxy) obviously has first mover advantage in this market and the acquisition by Microsoft set off alarms at Google. This is maybe the first time there truly has been a threat to Google’s main revenue source, search. The ability to drill down into a response and clarify exactly what you mean instead of trawling through page upon page of google results could see the end of ‘search’ as we know it. Microsoft has already announced that they’re going to incorporate ChatGPT into Bing. It’s legitimate for Google to be concerned about OpenAI and other industry disruptors (I’d be surprised if the other industry megalodons haven’t been investing heavily in AI tools) as they risk losing the monopoly they have on search. They would go on to announce Bard, a direct competitor to ChatGPT. Google has also recently invested nearly half a billion dollars in Anthropic, another competitor to ChatGPT (incidentally started by former employees of OpenAI).

Will Bard be better than ChatGPT?

Other than the questionable choice of the name, we do not know what Bard will be like. In the announcement blog post, Google mentioned that they will initially be launching a smaller model but gave no indication of the size of that model. It’s important to note here that the size of the model doesn’t necessarily mean it will be “better”. As mentioned earlier, it could just mean the model is better at people pleasing. Google has been publishing immense progress in the Artificial intelligence sector however, MusicLM is a prime example of this. It seems that Google has made huge strides forward in this sector but has not mastered the commodification of it as OpenAI has. The competition will certainly drive innovation.

What does all this mean for the computer programming industry?

Google’s Deepmind’s mission is “Solving intelligence to advance science and benefit humanity”, aka solve intelligence, then solve everything else. I think in the immediate future (next 2 years) these AI tools will be just that; tools to help Engineers build, beyond that it’s difficult to see how advanced they’ll become and whether they actually will replace Software Engineers. Tools like ChatGPT and Github Copilot can already generate pretty robust code (although this depends on the training data again, provided buggy code the models will generate their own buggy code), it’s not hard to imagine for an AI to generate a whole website or mobile app complete with the Xcode build files etc. I wonder how far away from that we actually are.

If you want to go deeper into this subject here are a few videos I recommend:

• ChatGPT with Rob Miles — Computerphile
• Anything by Rob Miles on this subject in fact
• Google Panics Over ChatGPT [The AI Wars Have Begun] — ColdFusion

Originally published at https://www.brightec.co.uk.

In-app Messages are messages you send to your users in response to actions they take in your app. This powerful functionality can increase engagement and customer buy-in. You could certainly imagine using these messages to drive a featured product or app personalisation. Firebase offers this functionality out of the box, however, it’s fairly complex to customise the behaviour of these messages.

The Firebase docs recommend editing the storyboard files in the library directly. Although this is fairly easy to do it comes with one notable drawback; you’d be unable to update the library without having the headache of migrating changes you make to the storyboard files.

But there is an alternative.

Displaying custom messages

Although Firebase has all the necessary functionality for the messages (including the analytical events), we found that the default had a certain “Google-y” look and feel which didn’t fit the brand of the app we were writing. So, we decided to create our own views which did match the brand. We discovered that we could implement “InAppMessagingDisplay” when importing “FirebaseInAppMessaging” which allowed us to decide what view to display in response to the type of message Firebase is wanting to show.

Here’s an example of how we did that:

We basically switch on the “type” of “InAppMessagingDisplayMessage”. It’s important not to forget the delegate methods here i.e when the message is displayed/dismissed calling the relevant functions to tell firebase X message has been displayed and dismissed, this allows Firebase to queue up messages and makes sure the subsequent messages are displayed correctly.

In creating our own custom views we have more control of when to show certain types of messages. For example, we wanted to improve the opt-in rate of people accepting notification permissions within the app, to do this we thought targeted messages in response to certain events (such as a purchase or a product coming back in stock) with custom wording reflecting the action taken would improve opt-in rate.

The problem here is that we wouldn’t want to show this message to users that had already opted into push notifications. Firebase wouldn’t know which users had opted in or not and so the out of the box messages wouldn’t be able to make this distinction.

In our new customised message manager, you can do this in a couple of ways. You could either check the status of the notifications when you see a certain URL in the action button, or check a certain field on the additional data fields within the message. Remember if you decide not to display a message you must call the dismiss function on the delegate to let Firebase know your app is ready to display another message.

Creating our own custom views unfortunately meant we had to rewrite the display logic of the views so the messages felt natural and would not just appear on the screen. When we display Cards, ImageOnly or Modal messages we grey out the background and animate the view appearing up from the bottom. This felt natural and inline with the UX of the app. For the banner we mimicked the behaviour of standard iOS notifications, the view appears at the top for a number of seconds before disappearing.

Given that we have now implemented “InAppMessagingDisplay” we are able to customise the messages we want to display to our hearts content.

A note on versioning; when we add new views/actions to respond to messages we have to be mindful of the version of the app that they exist in because they’d require a new release to display. We keep track via confluence of what message/action is in what version and make sure we only target that version in the console when setting up a new campaign.

Originally published at https://www.brightec.co.uk.

How to customise Firebase In-App Messaging on iOS was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’re reading this blog post, you have probably felt the pain of a 4,000 line pull request with no description or context.

No one should roll their eyes and groan upon opening a pull request. If you share the belief that the onus of making them a pleasure to review is on the engineer putting up the pull request, read on.

Pull Request Templates

We’ve recently started using pull request templates at our company. Pull request templates provide a template for the engineer to fill in when writing a pull request.

We don’t enforce descriptions in pull requests however I’ve found if you include a template the engineer will likely fill the fields out and provide the reviewer with some context.

This is especially useful when you are reviewing a feature/project you’re not currently working on. To add a template to your project you’ll have to create a pull_request_template.md file, this can be visible at the root of your project or hidden inside a .github/ directory. Here’s the template we’ve adopted:

This template is useful as the engineer thinks about the change they’ve made in plain English, thus making the pull request clearer for the reviewer. More information about pull request templates can be found here.

Restrictions on Pull Request Sizes

Imposing a size limit makes pull requests more concise, and easier for the reviewer to digest meaning they may be able to catch any potential mistakes, using less effort.

The relationship between cognitive load and the size of the pull request is exponential — at a certain size, the reviewer won’t even read the code and bugs will slip through.

To combat this we’ve imposed a size limit of 400 lines of code on pull requests. Under this limit, we sometimes need to break down features into multiple pull requests (i.e SQ4–123-a, SQ4–123-b, SQ4–123-c, etc.) and have found code review more effective in doing so.

The commit history does become slightly messier however we feel it’s a worthy tradeoff; the less the reviewer has to think about, the more they’ll catch in the review.

A 400 line limit might not be right for your project. There’s an interesting tool here which benchmarks your organization against others in the industry.

What Tools To Use On GitHub

There are several code pull request tools that make reviewing code that much easier. Here are a few of my favourites:

1. Reviewable — This organises the review in a nicer UI than Github’s native view, it has plenty of keyboard shortcuts to aid when reviewing. You can also review by commit if you want using Reviewable.
2. GitHub.dev — Did you know that if you press . whilst on a GitHub repo you’ll be taken to a web version VSCode? This works for pull requests as well, you can clearly see all the files changed and make comments in IDE as you please.
3. Better Pull Request for GitHub — Similar to above this chrome extension will let you browse the files changed in an IDE-like tree structure.
4. Codacy — You’ll be able to remove mundane code review activities (such as code style) with this GitHub application which automates some aspects of code review.
5. Pre-commit/pre-push hooks using Husky — these tasks that are run locally before you commit or push code; they can do such things as run tests, run lint checkers and check commit messages and they’ll catch things that could have otherwise slipped through. This should simplify the code review for the reviewer.

Self-review

It’s always worth considering; would you enjoy reviewing your own pull request?

This is a technique that I use personally. As silly as it seems, I pretend that I’m the reviewer and review the code I’ve pushed myself first before asking anyone else to.

I leave comments for myself and resolve them once I’ve fixed them. Even with all the tools I’ve written about above I still catch things in reviewing my own code. After that, I’ll then request a review from somebody else and hopefully, I’ve made it more pleasant for them, as well as reduced what could have been missed before it is merged in.

With these tools in your arsenal, you can make pull requests less painstaking, maybe even enjoyable, for the reviewer. If you have any more suggestions, please let us know. We love to hear and explore new ways to improve our process.

Originally published at https://www.brightec.co.uk.

How To Create Pull Requests Which Are a Pleasure To Review? was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Using Google Pay and ThreeDSecure with the Braintree Drop-in UI returns a CardNonce instead of a GooglePaymentCardNonce. Here’s the solution to that

We were recently tasked with implementing a new payment integration using the Braintree Drop-In UI on one of our apps. However, we ran into an issue when requesting ThreeDSecure using Google Pay.

ThreeDSecure provides an additional layer of security for online credit and debit card transactions, an essential protocol if you are processing card payments. Braintree offers an easy way to implement card payments as well as integration with ThreeDSecure. It also offers an equally straightforward way to implement Google Pay.

Do you need ThreeDSecure with Google Pay?

There are two types of card that can be used with Google Pay, PAN cards (non-network tokenized standard credit cards) and DPAN cards (network tokenized cards that have a generated virtual card with a device-specific account number). ThreeDSecure is not available with DPAN cards as they are considered already secure. However, you will need to implement it when using PAN cards. The Braintree drop-in UI detects the card type and will handle this implementation automatically if it detects a PAN card and you have requested ThreeDSecure. You can do this with the following Kotlin code:

It is highly recommended that you use ThreeDSecure with PAN cards to improve their security.

What did we do?

We opted to go with the scenario where the user explicitly fills out their details (such as email and address) and we can then use this information to authorise the payment. We used this as an opportunity to measure the “quick checkout” conversion rate using Apple Pay on iOS (as Apple Pay does not require ThreeDSecure payments) to see whether moving away from the drop-in UI would be worth it. We anticipate that it will be and are also predicting to see an increased conversion rate.

All in all, the Braintree drop-in UI is extremely simple to use. However, you may have to compromise on the flexibility of the solution. Hopefully, this blog post will help people facing a similar situation and save them time when implementing ThreeDSecure and GooglePay.

What went wrong?

Unfortunately, we ran into an issue where the return type after completing a ThreeDSecure whilst using Google Pay. Normally the return type after completing a payment using Google pay without ThreeDSecure is a GooglePaymentCardNonce. This was not as we expected; it was a normal CardNonce when completing a payment using GooglePay and requesting ThreeDSecure. This meant that we lost the billing information that we needed to authorise the purchase.

We contacted Braintree and discovered that it was not currently possible for the drop-in UI to return a GooglePaymentCardNonce after completing ThreeDSecure. We would either have to explicitly get the user to provide their billing details (removing the option of a “quick checkout”) or move to Braintree’s hosted fields (a significant restructuring would be necessary to move away from the drop-in UI).

Originally published at https://www.brightec.co.uk.

How to Use Braintree Drop-In, Google Pay, and ThreeDSecure on Android was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’re trying to grow your instagram, Reddit is a great way to get your posts in front of more eyes and build your audience. If you try to post manually it can take a large amount of time and effort. This is why I found a way to post to reddit every time you post to Instagram.

The tools I use:

• Later (allows you to schedule Instagram in advance, optional to post to Reddit — free plans available)
• Postpone (the program that publishes to reddit — this costs $10 a month and the link is an affiliate that I earn a small commission on)
• Zapier (the program that links Instagram to postpone — this can be free if you don’t post much on instagram but can cost $25 a month if you post a fair amount)

The set up:

Step 1.

Set up a Zapier account and create a new Zap. Call it something like insta to reddit.

Step 2.

Add the trigger “New Media Posted in My Account in Instagram” and connect your instagram account.

Step 3.

I caption my Instagram posts in such a way that I can extrapolate the first line to use a title on Reddit. To do this add the action “Run Javascript”. Name the input data caption and select the caption from the drop down. Add the following code in the code section:

This will output the first line of the caption and you will use it later on.

Step 4. (Optional)

Add the action “Text” select “Transform” and select Convert to ASCII. Select the input to be the caption that you just processed. Some subreddits have filters that automatically flag your post if your title is not in ASCII so this is a safety step.

Step 5.

Next you have to upload the image to Imgur. To do this you need to register an application on Imgur. Make a note of your Client ID as you’ll need this to upload an image to Imgur. Add another “Run Javascript” action. There’s two input fields here; imageUrl which is the media URL from the instagram action and the imageTitle from caption Run Javascript action. Paste the following code in the code field and replace <IMGUR-CLIENT-ID> with your Client ID.

We upload the image to Imgur to ensure that Reddit displays the full image.

Step 6.

Finally add the “Schedule Reddit Post in Postpone for Reddit” Action (this is invite only from Postpone). Link your postpone account, add a relevant title for the subreddit you’re posting to, for example if you’re posting to r/ITAP they require the caption to be “ITAP of …” in our case it would be “ITAP of <Caption from step 4>”. Fill in the link section with the Data Link from the Imgur upload. Type the name of the subreddit you want to post to and the time you’d like to post e.g. “tomorrow at 1pm”(Postpone has a handy feature which averages when the previous top posts were posted for each subreddit if you need inspiration for when to post).

Step 7.

If the caption fits more than one subreddit then you can crosspost it to each in the above Action. Otherwise, you can add a second “Schedule Reddit Post in Postpone for Reddit” Action.

Using this method my posts have been upvoted 3500 times and have over 100 comments.

This can create a sense of community around your content and a great thing about reddit is that you don’t know what will get a lot of upvotes, there’s always a chance of going viral. If you’re an individual then this method may be slightly expensive however if you’re trying to grow a brand or would like more eyeballs on your work then this is a perfect fit.

Automate posting your Instagram photos on Reddit was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

React Native is a solid, tangible solution to develop an application at speed as 90–95% of the code will be shared across platforms.

Today we’re talking about something that falls into the category of not being able to be shared.

In a recent React Native project, we decided to use the Braintree drop-in UI integration to handle payments as an easy win when you’re using Braintree. This a great library provided by braintree (and then ported by wgltony to React Native) to save developers the need to build their own payment integrations. It’s easy to set up and get working for React Native by following the steps on the wgltony’s github repo. The only downside of using this integration on React Native is that it’s potentially harder to customise the UI of it. You have to delve into the native code in order to do so.

The Android Side

To customise the look of the Android Braintree drop-in UI you have to overwrite the styles that braintree have defined in your own styles.xml. Here is the list of styles you can overwrite. To do this you copy the style into your styles.xml, this can be found in the android/app/src/res/values directory. If it’s not there then you’ll have to create one following this guide. For example if you’d like to add a bit of your app’s style to the add card activity you can do that in the following way:

Our app’s style was a red app bar with a white title and the button’s text not all in caps. However, to recolour buttons you have to overwrite the colour that braintree has defined. In your android/app/src/res/values/colors.xml include the following:

This is mentioned in the issues of the braintree android github.

That code produces this layout:

How about iOS?

The documentation surrounding how to customise the iOS braintree drop-in UI is more complete than that of Android but it’s still worth running through. You can customise a number of properties on iOS including:

• The text color
• The overlay background colour
• The navigation text colour
• The form’s background colour
• The navigation bar’s background colour

Here’s a list of different properties which you can edit in iOS. You can set these properties before initialising the braintree UI. The following code snippet would give a similar look to the android version above:

All in all the braintree drop-in UI is an easy tool to use to handle payments. Customising it is fairly straightforward but requires some native knowledge when customising it on react-native.

Originally published at https://www.brightec.co.uk.

How to customise the Braintree dropin UI in React Native was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Brightec we are colleagues but we are also friends. We value our connection as a team and whilst another lockdown means we can’t meet socially, or share lunch times in the same way, it hasn’t beaten our spirit. Since working remotely we’ve started a weekly catchup on Friday afternoons. The agenda is casual; we mostly play games as we’ve found it’s a relaxed and easy way to chat whilst having a focus which encourages more natural communication as it would around the lunch table. Here’s a list of our favourites:

Among us

Among us has recently taken the internet by storm. It’s free to play on mobile or paid on PC. In this game you are little space beans attempting tasks to either repair your spaceship or base. But, there is an imposter (or two) who will try to kill you. Your job as a crewmate is to try and discover who the imposters are. If you are the imposter then your job is to kill all of the crewmates. Once a crewmate discovers a body they will report and discuss all their findings during the round. This discussion is where the fun comes from with the imposter trying to cover their tracks or frame other people and the crewmates playing detective. This is truly a great game to help the team feel connected and laugh together.

Skribbl.io

Skribbl.io is a free drawing game. One person draws one thing of the three prompts and the other people try to guess. It’s best played on tablet or desktop and is especially fun when you are woeful at drawing (like me). We like to join a video call and chat throughout the game although admittedly it is mostly making fun of my drawings.

SuperTuxKart

If you’ve played MarioKart in the past you will love SuperTuxKart. This free to play game is available on Mac, PC and Linux. It’s a great little game which is basically a budget MarioKart. There’s a huge selection of maps and there are a few different game modes. It’s full of nostalgia and a great game to play whilst on a video call. The soundtrack is banging too.

Coup

Coup is a bluffing card game. The aim is to be the last alive. You don’t know what cards your opponents have but you gather information throughout the game to determine what people have. However, your opponents can bluff and fool everyone. This game was one of our faves back in the office but we found that Chris Brown made an online version of the game.

Jackbox

Jackbox is a collection of party games that work really well remotely. They have 7 party packs with 5 games in each pack. The prices vary but only the host has to pay. Our favourites are Quiplash, which requires you to come up with the funniest response to various prompts . We also like Trivia Murder Party where you answer obscure trivia questions interlaced with minigames.

Checkout our other suggestions here.

If you have any more suggestions of games be sure to leave a comment and let us know. We’re always looking for new ones to play.

Originally published at https://www.brightec.co.uk.

Perhaps the most important part of software development is acquiring feedback from users. There are multiple efficient ways to do this for mobile app development. Two of the most prevalent are Firebase App Distribution and Testflight. Here are the pros and cons of each and what we use them for.

Testflight

Testflight is Apple’s solution to distribute iOS apps to users that are willing to test your app. Being from Apple it was always going to be a streamlined, painless process, however there are still a couple drawbacks. Here are the main advantages:

• No provisioning profile steps for testers — this means it’s super easy to manage users.
• Easy bug reporting/screenshot sharing features for testers built in.
• Easy to open up to the whole community with the public sharing link.
• No extra sign up.
• If you’re happy after the testers have finished you’re able to submit to the App Store straight away.

The main disadvantages are as follows:

• Need a (Beta) Apple review before new builds can be distributed — this is usually fairly quick but can take up to a week which can be frustrating.
• Testers need to download the Testflight App.
• Limited number of testers — although this is fairly large at 10,000 users, larger companies could potentially need a fair few more.
• Not cross platform — this is included as Firebase App distribution is cross platform.

Firebase App Distribution

Firebase is Google’s suite of products catering to app development. App Distribution makes up part of this. It’s fairly easy to set up and useful for various reasons. Here are the main advantages:

• Test cross platform — meaning you can upload your Android APK and your iOS build to the same service and distribute them to the appropriate users.
• There’s no limit to the number of users that can test the app.
• Easy to implement if you already use Firebase analytics
• Simpler to compare and manage different beta versions

The main disadvantages are:

• Painful provisioning profile updating for new users — meaning you’ll have to update the iOS provisioning profile for each new user in order for the user to install your app.
• Users have to create an account.
• Extra Firebase libraries added to the project.
• Not as seamless an experience as testflight.

Use cases

We use both Firebase App Distribution and Testflight to gather user feedback, our internal policy is to use Firebase App Distribution when the app uses a staging or dev API as opposed to a live one. It’s an extra layer of security to ensure that we don’t accidentally publish an app that uses the wrong API.

You may be in a similar situation or you may prefer one over the other, both are tangible solutions to gather user feedback.

Originally published at https://www.brightec.co.uk.

Firebase App Distribution vs Testflight was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been building mobile apps professionally for two years now, however I’ve only recently built an iOS app from scratch as a side project. This blog post is a summary of what I’ve learned and resources I used, I hope it will help or inspire you to get started on your own app.

Starting strong

Perhaps the most important part of the process is the beginning, this is where you’ll lay the foundations to ensure that the project is easy to come back to and a pleasure to work on.

Wireframing

With mobile apps I find it crucial not to develop blind, i.e you should have some idea of what you’re building and how it will look. To help with this you can do a quick sketch, either on paper or digitally. This helps inform what the entire app will look like. Below is a quick wireframe of the side project I was working on, an educational CBT app.

Here are some free resources to help you design a wireframe:

• Canva (free digital design resource)
• Adobe Color (free colour palette generator)
• Google Autodraw (free icon generation)
• Sketchize (free wireframe layouts)
• Miro (a free collaborative whiteboarding resource)

Planning

Once you have some idea of what you want to build then I suggest you break down the tasks you can think of into small manageable goals. This way you will avoid burnout and track progress efficiently. I recommend using Trello to track these tasks (easter egg: put 🎉 in the done column and drag a task in there).

Choice of technology

At this point you’ll probably know what you want to write your app in but you may not know how to architect your app or what the backend will look like.

Application Architecture

The architecture of an application is important, it ensures that all the applications you write will be consistent, easy to work on and easy to pick up again. There are several architecture choices when it comes to native development, these have the goal of avoiding bloated classes (especially ViewControllers in iOS and Fragments/Activities in Android) and spaghetti code. Here’s a brief summary of a few that we’ve looked into at Brightec:

(MVP pattern source)

The view represents a ViewController (or Fragment/Activity), the view is dumb (contains no business logic). The presenter addresses all UI events on behalf of the view (i.e what to display when) and calls the data methods in the model. There can only be one presenter for each view. The model represents the data portion or business logic of the app (the comms with the backend, processing data etc.). Here’s a great blog post if you want to go more in depth with this pattern. This is the pattern we mostly use on iOS at Brightec, it’s also the pattern I used for the side project.

(MVVM source)

The model again represents the business logic of the app. The view in this case again represents a ViewController (or Fragment/Activity). The ViewModel is where this architecture differs from MVP, it can be used across multiple views. The ViewModel exposes streams of data that the view displays. The view subscribes to data events which are updated in the ViewModel. MVVM leverages the separation of concerns of MVP but also employs the advantage of data binding. This cuts down on the logic in the view. Brightec uses MVVM in its Android applications. To continue reading about MVVM, there’s a blog post here

(VIPER source)

By far the coolest architecture name. The view is the same as above. However, the presenter contains the view logic to display data, which it receives from the Interactor. It also contains the logic for reacting to user inputs, which it requests from the Interactor. The Interactor mediates the interaction between the Presenter and the data. The entity is a basic data model. The Router contains all the navigation logic. This is a further abstraction to MVVM and MVP as it separates the display and data logic of the presenter. Further reading is available here and here.

Backend technology choices

I am no expert on backend/server development so this section is just my recommendation of free services to get you started if your application requires it.

Possibly the prominent free service you can use to get started is Google Cloud Platform (GCP). Google offers a plethora of services including serverless functions, dedicated services, databases, etc. We used a combination of Google Cloud Functions and Google App Engine for the backend of a Slack app we developed recently. GCP integrates with Firebase seamlessly. Firebase is a free collection of services that help developers build better apps. The services include; analytics, crashlytics, app distribution, cloud storage and many more. I exclusively used Firebase to power the backend of the side project I was working on as the free tier allows for a fairly generous number of interactions with the database.

There are alternatives out there like Amazon Web Services, however I’ve not used this much.

Communicating with the Backend

If your application requires a backend then you’ll need to communicate with it. This would be the Model section of the above architectures. At Brightec we use the repository pattern to achieve this. There’s plenty of frameworks for storing data locally once you’ve retrieved it from your backend. Some examples are Room, Realm or SQLite.

You should now be equipped with tools necessary to develop your own mobile app from scratch. I’ll soon be writing about how to test an app you’ve made by yourself and the benefits of developing a side project so be sure to subscribe.

Originally published at https://www.brightec.co.uk.

Build a Mobile App From Scratch was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.