DEV Community: Jonathan Lacanlale

Coming back to DEV

Jonathan Lacanlale — Fri, 10 Apr 2020 03:30:55 +0000

So just recently I got this email

which was cool and somewhat bittersweet because my last post was actually in mid-2018. I didn't actually stop posting for any specific reason other than I'm still a university student and I did get into academic research. Since then however, quite a bit has changed (and from what I can see, DEV has also changed quite a lot too.) So as a fun tribute post, I'll be picking out some developments that occurred since my last post.

Right before I stopped, my profile looked like this:

I'm fairly certain this was before you can change the UX of DEV, and before the actual app on the iPhone (both of which are amazing btw, thank you to everyone that made that possible.) A big change is: I'm no longer a mobile researcher anymore! I've actually rotated in research fields quite a bit, testing the waters of wearable technology, natural language processing, and computer vision, with computer vision being my primary focus. I'm still in my undergrad with a year to go before I apply to grad school for my PhD so there's quite some time until then. I actually have not touched Kotlin or anything Android related since then.

The primary thing that has remained consistent throughout my progress is machine learning and finding optimal ways to use machine learning models. This has largely become a big focus for me and it is something I plan on continuing in graduate school. Some fun little achievements I've made in that two year span include:

My first conference presentation
A few academic posters
Experimentation in different fields
And a clear long-term goal

The title of this post is "Coming back to DEV" and I mean it in the lightest sense. I'm not sure how often I plan to post but I have been taking up some work to keep me busy during the Stay-Home order which I hope to write about in the near future. Thanks to DEV for keeping the community interesting and reeling me back in with that Two-Year badge :~)

How I take notes

Jonathan Lacanlale — Mon, 27 Aug 2018 19:19:20 +0000

Taking notes is something I consider essential to a learning process. Generally, if I'm trying to learn a concept, whether it be for school or my own learning desire, I try to take notes that are meaningful, something I would be willing to read sometime later, and happily show to others. My usual process is to always start messy and move the messy notes into a separate notebook; one that's neat with helpful visuals. These visuals tend to be drawings or multi-color text that helps me distinguish topics like vocabulary, conceptual explanations, hypothetical usage, and do's and don'ts.

Here's an example of me learning about Python classes and object-oriented programming in Python:

Pretty messy right? These notes are what I take as I'm learning, whether that be through video or reading. I don't want to disturb the flow of either learning process, so I typically don't pay attention to how pleasing my notes look, but rather focus on how useful my notes are.

Once I've finished the rough learning, I then take the time to revise my notes in my neater notebook. I'll generally clear a whole page or two based on the subject and write down the biggest takeaways alongside the information that I found to be the most useful.

Now that I have a clear section, I'll re-read my notes to determine what I would want to keep or throw away. I generally like to mark the order of what notes move in first, and cross out each section as I go. This way I prevent myself of writing down the same thing and keep a clear track.

I'll continue this process up until the very last section and voilà! A nice section on Python classes and OOP that I can refer to in the future

If you take notes and have any tips or recommendations, I'd love to hear them! I absolutely adore seeing other people's notebooks and sometimes even draw inspiration from them so please do feel free to share!

TIL about paste

Jonathan Lacanlale — Mon, 13 Aug 2018 21:01:37 +0000

In a large chunk of my work, I've had to deal with cleaning and combining multiple data files. Today I learned that bash has a simple command called paste. Here's what the manpage says

Now that's a lot to digest but how is it useful? Well I have two files here, fileone.csv and filetwo.csv

I generally don't like wasting lines of code to read in multiple data frames so I usually want to combine them. Now, it takes more than just a simple paste fileone.csv filetwo.csv > combined.csv to combine them since the output is this:

This is because paste merges the files. No replacing character is specified. For my work, I use

paste -d"\n" fileone.csv filetwo.csv > combined.csv

to achieve the output I desire:

Now all I have to do is delete a single row. Yes you may have multiple csv's combined, but your header row gets moved to the top regardless, making deletion much easier. Extra ease if you're using Vim :^)

I finally took the dive into live-coding!

Jonathan Lacanlale — Mon, 04 Jun 2018 02:54:59 +0000

Ever since I first saw someone actually live code (which was probably only a month ago) and finish a project from scratch, I've had this huge desire to try it myself. Although I really wanted to, there were a few things that held me back (or so I thought). A large majority of these thoughts ended up being myths that have even been broken down by some streamers when interviewed on podcasts or even openly explained live. So here's a few thoughts that I had prior:

Of course before diving in, I would have to prep myself with notes and all, right? Well no not true; in fact there's a fair amount of streamers (awesome examples are Daniel Shiffman and Suz Hinton) who simply go live and dive in without the full plan and blueprints. So how do they go about planning? They plan live, which turns out to be a lot of fun too!

I'll need to make a good plan so I don't embarrass myself making a mistake. Although good plans make good starts, they're not perfect. In fact, an absolutely awesome plan doesn't prevent little errors that get missed in logic or syntax. The best part of it all is that all developers end up hitting stops so making a mistake is totally fine.

I don't think the equipment I have is right though, and no one wants a low quality stream. Although quality is always nice, code isn't exactly a 4K demand. In fact, I streamed from my mid-2012 MacBook and used the mic! If it's your first time streaming (and this was also advice given by streamers), you won't have any idea if you'll even like it enough to buy high-end equipment. Use what you have (or buy the cheapest at that) and try it out.

Well I don't know what I want to stream, or if it's something people would want to see! Chances are, not knowing what to stream is partly a lie. The thought of what can be done live may not have been thought through entirely, but just enough to know that there is consideration for it. That's a good start, you know you want to do something live, but what? Maybe a project you've done before; or a project you've been wanting to do; or maybe it's a finish project that you want to test and clean up. As for something people want to see, yes it's great to do things people enjoy, but streaming is almost like a side project. You don't make side projects for others, you make it for yourself. You want to improve or learn or have fun on your own whim.

Now I'm no expert by any means, in fact I just had my first stream a few days ago. But do I know that it's easy to not dive in because of a few little thoughts and doubts about the experience. Reality is, there is no "I'll do it when I'm ready" because it's virtually impossible to know when you're ready. Take the dive and if you hit a stop, take a breath and work through it. I hope this helped anyone who was/is considering streaming jump right in!

If you're curious about what I did make on stream, I played it simple and made a Jupyter notebook of a theme parks' annual pass, available here:

Disneylands Annual Passes (github)

and if you want to see me stream (which I'm hoping to strike a consistent schedule for Friday nights but that's still in the works) then you can find me here:

Twitch

How did you figure out your field?

Jonathan Lacanlale — Mon, 14 May 2018 00:59:16 +0000

It's always fun to see awesome projects that other devs made whether it be in web, AI, mobile, etc etc. 90% of the time it's a huge inspiration to beginner devs (like myself), however there's so many cool fields to try and choose from, I want to ask the question:

How did you end up in your field?/What made you want to get into your field? (field defined as, but not limited to, mobile, AI, research, DevOps, server-side, etc.)

Competitive Programming, a beginners POV

Jonathan Lacanlale — Tue, 01 May 2018 14:48:46 +0000

Beginning developers are often encouraged to engage in external practices, most of which consist going to meetups, attending conferences, and participating in competitions. Although all of the above is fun, educational and extremely memorable, there is a lot unsaid about what some parts feel like. What often isn’t covered is the underlying anxiety of breaking out of your comfort zone, or how hard some experiences may be.

Last weekend I participated in my first competition, a time frame of just under 24 hours to create an Android application aimed towards helping others. I competed with friends and we were a team of five with very different levels of experience. Competing revealed aspects of software development and soft skills that did not seem so blatant, all of which paved the way for different lessons to be learned. Here is a list of such truths that I discovered and what can be learned from them:

Everyone has some specialty and you may not even realize it. It may seem somewhat like a given, but it’s more of an assumption. You never truly see what your friends or teammates or classmates are capable of until you’re all given a moment to utilize your skills. Even a brief “Yeah I do ___ on the side” is lackluster in comparison to what a person (even yourself) is really capable of doing in a given amount of time.
Sloppy code is better than no code. For every amazing, well-read, articulated piece of literature, there existed some terrible first draft that is kept hidden; even this post had a terrible first draft, why not do the same with code? Most code written on the first try has aspects that can be improved whether it be syntax or logic. That’s why refactoring is encouraged, in an effort to make code much more readable and efficient. There’s nothing wrong with starting out messy, so long as you take care to revisit and make the proper improvements.
A working project with a minimal UI is better than a UI that does nothing. It is hard (near frustrating) to not think about how pretty and pleasing you want your project to look, especially if that is what you enjoy the most. By creating the logic and functionality of a product before the UI, you’re able construct the core functions that make the bulk of the application. If, during the function design, you decide “Oh, this piece would help!” and would take minimal time, you’re able to do so without having to redesign the entire UI. However, making the UI first restrains you to what you have initially thought of, barring you from new ideas that you would enjoy implementing or what you think the user may want.
Competing is fun, just don’t forget to break. Drink some water, stretch, and have a snack (or even a meal if possible.) Seriously.
Communicate. Both you and your team have different thoughts about what should come first, what should be prioritized, and how to complete objectives. No one is capable of reading minds, so make effort to say “Hey let’s get _____ done before the hour ends” or “I’m going to do _____ this way, what do you think?” You and your team’s input on how the project is going is just as important as the output to be delivered.
Regardless of what you’re working on, be quick to ask for help. It’s frustrating sometimes to be amongst talented and hardworking individuals, while you’re stumped on a single issue that even a stackOverflow search won’t solve. However, just because you need help doesn’t make you any less talented than your teammates. Guaranteed that they hit a hard obstacle and spent the same, if not, more time to find an answer, however the longer you spend without succession is the longer amount of time that has been wasted. Remember that you and your team are all composed of different and talented minds, so it is highly possible that someone could offer insight on how to overcome a problem
Enjoy yourself. It’s cliche and it’s overused but it is 100% true. Yes there may be an end goal whether it be a cash prize or a job opportunity, however at the end of the day you gain the developmental experience regardless of you win or not. You learn how to perform tasks that may have seemed unimaginable prior to competing, as well as networking with individuals who you thought you would have never seen in such a setting. Focus on learning the skills to try to finish what you started, and find out what you can learn from other people in the process. This is not limited to your teammates, but the other teams as well, and this is where high competitive spirit needs to be set aside. Breaks are the best time to talk to other competitors, most which are just as frustrated, stressed, and tired as you are. The best laughs and jokes and memories come from these moments amongst you and everyone else at that competition. First place is nice, but it’s nice, if not, better to have fun and not forget to learn a few lessons along the way.

It can be intimidating at first, and it may feel like some kind of club of elites competing for the grand prize. Realistically, it’s just a group of ambitious minds that want to try their skills. I used to think “Competitions are way too cut-throat for someone like me to join” until I actually gave it a shot. Now it’s become a huge desire to continue. Take the chance, be willing to try and learn and do something different, and enjoy yourself!

This post was originally made on Medium! I also run a blog where I post about my projects and interesting tidbits I find through my programming experiences :] Check it out! http://lacanlale.weebly.com/