Edge Case: A Developing Blog

by Stazman (Christopher DiStasio)




programmer-using-laptop-on-cliff
A typical day with the Mac.



Webopedia's Term of the Day
Check out today's term of the day:
Today's Term




My Coding Journey

It's my hope that reading about my experiences can help you on your own coding journey.


April 27, 2018

I finished my first major web app! You can check out the github repo here:

Small Business Website with User Accounts Repo.

And here's a video run-through of the app:

This project sent me further into the deep back end of programming. I learned how the vast majority of web apps are structured and developed, according to CRUD specifications and MVC structure. I learned something of sessions and cookies, and of encryption with the bcrypt gem, and I learned the importance of validations of common kinds of data users enter into a web app. I've used good ol' Ruby language but only as a kind of glue between frameworks, libraries, and gems such as Rake, Rack, ActiveRecord, and Sinatra, which provide the overall structure, functionality, and organizational efficiency for a web app. In terms of programming habits and principles, I've developed quite a few more, which I use on a systematic basis. I developed a method of studying (many years after being in school, mind you) that suits me very well and which has enhanced my learning immensely. Most of all, what is exciting in terms of my personal growth as a programmer is the pure facility I have with code now. It feels much less like learning a foreign language -- from a different language family entirely and on a different planet, even -- and more like second nature. Not only am I blogging about my experience coding, there are several topics I want to blog about not just as a learner but a MAKER.




February 23, 2018

I passed my CLI gem assessment! My gem is here if you want to set it up and try it out in your own IDE:

.

After I passed the technical interview part of the assessment, I was asked to refactor the gem, which took me less than an hour! I really know my Ruby code, and I can quickly do what needs to be done to make it better!




February 15, 2018

Trying to think of an object in object-oriented programminmg as a literal, physical thing is like trying to grab a hologram.




February 9, 2018

With a little amazing help from a tech coach, I made my cli, the user interace, rely on the model rather than a class that only did the scraping, which makes for much better code according to best practices. And this is the new principle I learned from that, because it was a point I was stuck on and didn't think there was a solution for: there's a solution for everything; you just need to find it. Of course, ''just finding it'' can be a lot more complicated than it sounds, and you have to deal with constraints of time, clients, and sometimes investors. I got the cli to work, but when I had time, I made it better. I do believe that's a value as a programmer I can bank on :)




February 6, 2018

Whew! I'm finally finished with the gem project. Although I know there's more I could have done with it, I've learned a lot through it and I'm happy with what I've done. Most importantly, it works! As for my experience, you can get a strong sense of what I went through from the principles that I gained from the experience:

  1. You need to use both the literal and the abstract. You can ''think abstractly'' but only to a point. You need to use literal examples (As Avi Flombaum points out), plugging in real instances, objects, and methods, to make sure the abstract works (and not to cause a nervous breakdown on your quest to become the most amazing coder in history in a few months time :))
  2. Don't rely on conditional statements to do everything. If your conditional statements aren't working, consider breaking the statements up into separate, interactive methods. This fits the individual responsibility principle -- a fundamental aspect of programming -- very well, too.
  3. Don't just scrap everything and start over if all else is working.
  4. Plow through the coding. Let this be the tendency rather than to start over all the time, especially when there's no error.
  5. Success at coding is not knowing it all; it's knowing enough to Google.
  6. Don't finish until you finish. You never know if a bug will show up at the last minute. If you think you're already done, this bug turns into a monster.

And these are the principles I've learned so far in total, at this point halfway through the Flatiron curriculum:

  1. Less is more ... keep it simple.
  2. Take time to look for the right method.
  3. Review previous code carefully to see what might already be useable.
  4. Be careful with cut and paste ... use it sparingly as you go rather than cut and paste a lot of code and then make what you need fit it.
  5. Just because something lets you pass a test doesn't mean the test won't break later on.
  6. If an expression doesn't work, consider assigning it to a variable.
  7. Break everything down as much as possible.
  8. Stub regularly.
  9. Talk everything out to yourself as you work.
  10. Embrace errors.
  11. If there is documentation for it, read it. All of it. Carefully.
  12. Type in even code you're copying ... if you make a typo, it can show you what you don't know, not just be an orthographic matter.
From Avi Flombaum:
  1. Make one change, then get feedback.
  2. Read an error message carefully. All of it. Front and backwards. Look for clues.
  3. Use pry and IRB continually (with Ruby).
  4. Replace abstract values with literal ones.
  5. If something isn't working, YOU HAVE TO CHANGE SOMETHING. (Don't just do the same thing again and again.)
  6. Don't be afraid to get help.
  7. Google it!
    1. Don't just copy your code or error ... phrase it as a question!
    2. Use Stack Overflow ... blog posts and tutorials.



February 1, 2018

A lot of things that I used to see in my ESL students I now see in myself. And a lot of the things that I know were good for teaching and learning ESL are also good for learning coding.

Even though there are a lot of things that are similar between a new verbal language you're learning and a language you already know, it is easy to think of yourself as an outsider. That actually hurts you from using what you already know and what you have learned about the new thing.

In ESL teaching that is known as the affective filter. And now when it feels like I haven't learned anything, I know that actually I've learned a lot. And like I used to tell my students, it takes time to learn a language. And programming is definitely not any easier than that. It involves not just learning pieces of information and memorizing them, but also new ways of thinking in new kinds of logic.

And now I'm finding that what I used to tell students is what I need to be following myself. Learning programming takes time like learning a new language does. Also, sometimes the only way that you can learn some aspects of language is through actually practicing it. And that's a lot of the way it is with learning programming. Some things you can copy and some things you can learn from as examples, but in the end you really need to practice it on your own. Likewise, in language learning there are what are called chunks of language, in such phrases as ''how's it going?'' ''How's it going?'' really doesn't make sense literally in terms of what you're supposed to respond to; I'm asking how well you are, not about anything that is literally in motion per se. And the ''it'' in ''how's it going?'' could mean your feelings or your life, but it doesn't make sense literally. Still, it's understood.

So ''it'' is a chunk; it doesn't necessarily mean something literally directly. And that's how code is. You can learn something about code but until you see it practiced and try to practice yourself you're not really going to fully understand it, or as they say in language teaching, it will not be uptake.



January 29, 2018

What seemed hopeless yesterday, even this morning, seems a lot less hopeless now. There are many things that are hard about coding, and not all of them are about mind-boggling errors. It is hard to leave the computer when you have a problem you can't just work out, but that's what needs to be done. It's amazing how easy it is to forget that you've been in the same situation lots of times before, when you've been stuck in a spot that seemed impossible to get through, but then you did and then you moved on to the next thing. But you do fix the problem, and then you move on. It make not take the time you want it to take, but it can be done. And there is progress. Don't be disheartened.




January 28, 2018

One thing I've learned as I make my own ruby gem is that it is important to know what to copy from others and what to develop completely on your own. When you use someone else's code, it's important to remember that it's not part of an organic process you went through on your own, which much of programming apparently is.



Check out previous posts here:

Coding Journeys



Stazman's Best Free Sites for Coders

Digital Mockups Regex Testing
Webflow Regexr

Best Videos for Learning to Program


HTML, CSS and More
EJ Media