DEV Community: David Moe

Combine Email Bills Using Gmail API (Dropped)

David Moe — Thu, 07 Jan 2021 17:36:11 +0000

Reason for Dropping the Project

After a couple of months, I ran into a few difficulties that would require me to re-think my logic for writing scripts like this.

The refresh token expires after 7 days so you'd have to keep requesting token. This means this is not really automated anymore. For long lasting accounts, you could use a service account but this requires a GSuite account.
Found out about Google App Scripts. I'm in the process of migrating all this work into Google App Scripts.

I wanted to automate combining monthly bills to share it with your roommates so I created this script. Let me know what you guys think!

https://github.com/logicxd/Combine-Email-Bills-Using-Gmail-API

Preview from GitHub

Customizable and extensible way of collecting all your bills before sending out an email with a final receipt to your recipients.

From emails in your inbox:

To sending out:

How It Works

General idea:

Fetches Gmails with the labels you provided.
Runs each email through the scripts (that you provide) to parse the amount. This includes reading and attaching files!
Adds any additional custom scripts that you may have.
Finally, composes an email using the parsed data to create a "final" receipt to send to your recipients.

An example of how I use it:

I get utility bills on my primary email account.
Forward them to my dev email account. This is to limit what emails you can access using Google API for safety.
Create filters to label my utility bills by water and electricity.
Write email scripts to extract the amount.
Download code on my raspbery pi and schedule it to run every month to send me monthly aggregated bills 🎉.

Check out the GitHub repository for a more extensive writeup.

Programming on the iPhone with Shortcuts

David Moe — Wed, 17 Jul 2019 08:30:12 +0000

Once in a while, on the weekends, I wake up with the urge to check out what new apps are on the App Store. And this past weekend, I stumbled upon Shortcuts.

What is Shortcuts?

Shortcuts allow you to integrate different apps and automate actions together. If you're familiar with Alfred, it is similar to Alfred Workflows. And how you build your actions and events is very similar to the scratch interface. Shortcuts was developed by Apple and it was previously called Workflow. Now you know why I brought up Alfred Workflows 😃.

So What Can You Do?

There are tons of things you can do with it. Here are a few:

Send ETA with a button press
Share Location
Download files on the iPhone
Send pre-defined text message
And many many more

You can find a whole list of Shortcuts that other people have posted on ShortcutsGallery.

Making Your Own

These are pretty self explanatory if you have some experience with programming. You can do everything from setting variables, using variables, asking for user input from an input dialog, or show input result.

What makes Shortcuts so powerful is that you can integrate with many native apps. This gives it an edge over IFTTT which mainly gives you access to other published apps. I personally use both IFTTT and Shortcuts to suit my needs. Customize what you want and automate those repetitive tasks!

Xcode Debugging Techniques You Should Know

David Moe — Mon, 04 Mar 2019 07:34:23 +0000

Whether you are looking for bugs, figuring out how the code flows, or experimenting your new feature, knowing how to use the debugger will save you a lot of time. I use the debugger basically every single time I run my application. It is also an excellent tool to use to learn how programming works. I just wish school taught this in my early beginner computer science classes. Instead, I was first introduced this after two years when I did my first internship.

These are some debugging techniques that I use the most. I highly recommend reading through objc.io's debugging tips for a more inclusive reading.

The Basics

Quick overview of the basics. You need to know this. Period.

Step Over - execute the current line and stop before executing the next line.
Step In - go inside the method at the current line. If it's already run, finish executing the current line and stop before executing the next line.
Step Out - finish executing the current block and return to the caller.
Conditional Breakpoints - hit breakpoint only if it satisfies the condition.
Automatically Continue Breakpoints - executes the expression in the breakpoint and then continue automatically.
po - print out details about the variable. po myVariable.
e, expr, expression - execute the command. e myVariable = @"new".
e UIView *$view = (UIView *)0x0000 - create a variable while debugging.

All Objective-C Exceptions Breakpoint

Catch it before the crash. This exception breakpoint is a major life saver. When there is an exception thrown, the application will just crash and give you the error stack trace in the Xcode output. When this is enabled, you will hit a breakpoint right at the line before the application crashes. Then you can look at your variables and see what's exactly going on that's causing the crash.

To turn it on:

Open up the Navigator
Click on the 'Breakpoint navigator' tab
Click on the '+' sign at the bottom to make a new 'Exception Breakpoint'

That's all it is! But you can do more to get the most out:

When the breakpoint hits, set it so that the exception will print out the error message from running this command: po $arg1.
Set exception on 'Objective-C' only. This will ignore any C++ exceptions if you don't want to see them.
Right click and move breakpoint to User to keep this breakpoint across all your projects!

Return from a Method

Examples: thread return, thread return NO, thread return myVariable.

Great for stubbing methods. Quickly return from a method with the value that you want. Let's say that you wanted to test this method that can return multiple values. Instead of changing the value, re-compiling and running it, you can just put a breakpoint here and return the value that you want!

Skip/Jump Executing Lines

Examples: thread jump --by 2, thread jump --line 102

I use this when I want to skip something from executing. This doesn't always work flawlessly though as LLDB doesn't like skipping lines too much. Also, Xcode IDE will not know that you skipped line until you step over to the next line.

Import UIKit

Example: e @import UIKit

You hit a breakpoint and you want to print a view's bounds by calling po view.bounds. Instead of getting the view's bounds, you may have gotten some garbage output such as:

error: unsupported expression with unknown type
error: 'bounds' has unknown return type; cast the call to its declared return type

To fix it, you may have called it by calling it as a method and also specify the return type by doing po (CGRect)[self bounds]. Well, instead of typing all that mess every time you want to print something, you can just do do e @import UIKit and you will be allowed to do po view.bounds and all the other methods that comes with UIKit.

Update UI Changes

Examples: e (void)[CATransaction flush], caflush (with chisel installed)

Great for testing UI changes on the fly without having to restart after each change.

Snapshot of a View

Example: visualize myView (with chisel installed)

Wondering what the view looks like? Just run this command and it'll open a snapshot image of your view on Preview.app.

I don't use all of these all the time, but they are used more often than other techniques that you may have seen. I will update these as my preferences are changed or I learn something new. Let me know if I should be using something and it's missing from this list.

Things I Didn't Know About Being a Developer

David Moe — Tue, 22 Jan 2019 07:23:10 +0000

I recently started my first full-time job as a software developer. There were some things I realized that were different than what I had first thought about a typical developer as well as some that never crossed my mind before. Even though I had worked before as a part-time, I was juggling between my academics and work so I never never realized these things. So these are some of my experiences that I think will help current students and new grads.

Get Ready to Communicate

It's not that I hate communication, I really don't. To be able to walk over to your co-worker's desk to talk and solve problems is part of the reason why I left my previous job, which was going to be all remote work. But I didn't know communication would be so important. Most of the tales I've heard about being a programmer (mine included) was mostly being left alone to do your coding and finish your tasks so this was surprising to me. Maybe I just wrongly assumed that being left alone meant you don't communicate when you're just doing that through chat or calls.

You have to do lots of explaining and detailing. There were many cases where I would go over how the code works, how it was debugged, and what my thought process was. My goal is to try to say only the bare minimum that they need in order to understand what it is that they're looking for. Which also meant, learning to control my urge to pick at every minor thing that I see and knowing when to stop. Let's just say it's a work in progress.

Listening and understanding to people's explanations. Just coming straight out of college, most people I've had to work with were around my age and were usually from the area. At work, you may see talented people from all over the world with different background, ethnicity, and age. So working on understanding them and the task at hand is a very important skill to have.

You're going to be practicing public speaking skills. From standup meetings to performing demos, you'll have to do public speaking. And as you get more and more experienced, you'll be passing on the knowledge to others in the form of classes. So if you're shy, like me, be ready to try to overcome your fears. It does get better over time though.

If you want to work closely with the customers, you can try being a Software Consultant. They work closely with the customers, getting the requirements, providing suggestions, and demoing. You also have to talk with other developers on top of this, probably the most communicative job as an early to mid level developer.

Be Prepared Before Asking for Help

Your co-workers and seniors are usually willing to help you. They want to help you. It's just that sometimes it's easier to ask for help than trying your best first. If your question is project-specific that only the people who have worked in it may know, then it's no problem to ask. If it's problem solving, I try to follow these steps:

Did I try solving it in at least 3 different ways?
Did I take a break and then come back to it?
What questions might my seniors ask and do I have answers for them?

Number 1 and 3 are self explanatory. They're just there to keep you thinking about the problem. Number 2 because sometimes taking a break lets you see things a bit differently. Kind of like how you would write an essay and then later come back to it and become amazed at how bad you wrote it. Here's an article if you want to read more about it.

After you figure it out without any help, ask seniors to help double check your work. This step is probably the most important as this will introduce you to other ways of problem solving that you may not have been aware of before.

Sometimes you need to get things done fast and in these cases, it would be better to ask for help than to spend time trying to solve it yourself first. If there's a knowledgable developer free to help you that cuts down the time it would take you, then go for it.

Developing New Code vs Maintaining Old Code

Developers at a company just starting off will do a lot of initial design process and producing new code. Bigger companies usually already have products that have been made and done so they'll be building on top of existing code to maintain them.

While both skills are essential, developing new code may be more rewarding for less experienced developers. Developing new code will help with your growth in the beginning but it may get harder since you don't have much reference of good coding practices. On the opposite side, maintaining old code is harder to do in the beginning but you'll have a better knowledge after getting through them with help from already-written code.

Doing side projects can help you grow stronger in the weaker area. So if you're doing a lot of development already, you can look into open source projects to contribute to get you more practice. On the other hand, if you're already doing a lot of maintaining code, you can develop some apps on the side.

Your Team is Not Only The Developers

Most of the time, you'll be learning from your development team but there are a lot of other things you can learn from other department as well. Seeing how testings are done by the QA team will help you prevent bugs. Learning how the designs are made will help you think about better UI/UX designs. One of the tips that I got was to talk to the QA that will be responsible for checking your work so you can catch them early and save time by having less back-and-forth status updates.

Continuing Your Education

I wasn't going to put this section here on this blog but I am going to do it because of how critical this is. I knew that I would have to keep learning to keep up with the new tech in the field but once you're out of school and you start working, it seems like it's on a whole other level. It's not stressful as studying for exams, but the way you learn and study your materials is changed.

You have to look for resources to learn from. I try to listen to podcasts, read articles, and talk to my friends to learn new information. Because you're not getting the material from your professors who are explaining it to you, it's up to you to make sure that you challenge yourself.

Know that you'll have to learn and experiment with different technology for the rest of your life. It sounds like it's a lot of work and tiring but it shouldn't feel too much like extra work if you enjoy the material. With computer science being so diverse, I'm sure you'll be able to find something that you'd enjoy doing.