Thursday, April 24, 2014

Object, Class, Constructor, Instance, Literal String, Regular Expression, Cranial Explosion

A few days later than I'd like to be on an update here. I'm slowly reaching toward getting over one of those "my brain is full" slash "Where did my motivation go?" slumps.  I changed directions a bit and have been slowly picking away at Mozilla's JavaScript offerings as mentioned in my previous post.  It reads quite a bit differently than the 'For dummies' book I've been perusing. I'm running into a lot of concepts that for now seem over my head and unfortunately are muddying the waters a bit for one I have previously covered as well.  For starters, the challenge is both frustrating and pleasing. Frustrating in that I'm not fond of taking steps backwards while moving forwards, or forgetting/confusing previous knowledge while wrapping my head around something new. On the other hand, it is rewarding in that there is such a treasure trove of new concepts and new resources to plunder. The challenge is a driving factor, and limiting factor. Time to turtle up!

I've also been dabbling a bit on the Rock Paper Scissors script I got up and going a few weeks ago. I spent a few hours planning how I want a 'final' version of this product to look and behave, as well as a roadmap for how to get there. This includes physical drawings of the functionality of the code, and visual design of the user layout. After laying the groundwork, I spent a fair amount of time researching CSS3 and the capabilities as such. It has, to my enjoyment, come a long way since the original incantation of CSS. Specifically, I've been utilizing the 'animation' and 'transform' functions to layer several visual actions on top of another for specific elements of the page.

In doing so, I'm hoping to fill several knowledge and experience gaps. Re-learning the basics of CSS as well as picking up new (and developmental) functions will be helpful in moving forward with any web design. Layering multiple visual actions has been a bit tricky thus far, but has also been an excellent refresher for my creative mind. At some point, I will need to tie the CSS into the JavaScript, to modify the page layout on command with a visually stunning, modern look and feel in mind. Combining CSS3 and JavaScript will add to my repertoire as I continue to focus on learning scripting languages, and in fact, the long term project I have in mind will heavily include the meshing of CSS / JS - and I may even end up reusing some specific elements.

My current objective is to delve deeper into Mozilla's development site, and take a healthy amount of time going back to patch up the elements I am starting to let slip or question myself on. The RPS project is still on the side burner, hopefully I'll have some results to share soon.

Friday, April 18, 2014

Resource Numero Uno

Reminder to self:

http://gitbookio.github.io/javascript/

Take a break from the coding, brush up on the concepts!

Further reading:

http://www.theodinproject.com/courses?ref=home

Mozilla offers a great JS resource, as well as many others.

https://developer.mozilla.org/en-US/docs/Web

Saturday, April 12, 2014

Project Management 101 Introduction to Project Management.

I've given my brain a rest for today on the coding and cramming end, instead I began thinking about the next couple of projects I have in mind. Namely the address book, and another more long term idea I'm mulling over that I believe will be a great labor of love project.

I realized I'm in a good place to start looking at the bigger picture, outside of coding and coding concepts, and start thinking about what software development lifecycles look like. As I suspected before doing my 'rigorous' Googling, there are multiple models one could follow here, each with their pros and cons. This has got my brain churning over the logistics of various projects built for various clients within various team environments and how this might look from the perspective of a code monkey - working on bits and pieces to meet deadlines, and a project manager - putting the jagged pieces together to meet their own deadlines. I've realized that when I eventually make the shift into this field, I want to go in with my eyes on the big picture just as much as on my own tasks. While I haven't yet dug into many resources on this, it's yet another topic of interest to try and pile on to my growing desire for knowledge.

That said, I'm currently in the market for a tidy little piece of software development...software to help me plan and track these ideas and get them off the ground. I'm going in blind here, while taking some of the above in mind, I'm trying not to overwhelm myself with bulky planning software adding yet another layer of learning on top of everything else. The features of the software or software package I need seem simple enough:

-A visual planning apparatus for a design roadmap
-Timeline and task breakdowns able to be built for an individual in mind in lieu of an entire team.
-Feature changes tracking / revision history or some other fancy sort of note taking addon.
-Ease of use, as in really, really easy.

These 'features' will I'm sure have different nomenclatures in the programming community (hey I'm still pretty green to this), but I'm sure I'll connect the dots. Maybe someday I'll write up a review of different types of such software, who knows.

What I don't need, at this moment, is something as complex as SCRUM or some of the SCRUM derivatives. Which seem to have a focus on tasks broken up into teams in a much more dynamic and fast paced environment than I'd be facing for the time being.

To close, I found this tidbit of information I thought worth saving via a reddit thread from one of the previously mentioned subreddits I'm subscribed to.

The original post is a novel question, which seems simple enough, asking for tips on collecting requirements from clients before a project begins. The top comment provides useful insight:

Identify problems. Problems are what you are building a system for. Don't let them make design decisions for you.
Example from today's meeting: the business I work for has indicated that payments of a certain type must not cross fiscal boundaries and if it does it must be broken into two payments, the first ending on the last day of the current fiscal year and the second starting on the first day of the next fiscal year.
This is a design solution. It doesn't tell me the problem. The problem is that the budget allocated to payments of this type is tracked by fiscal and needs to be both communicated to the people receiving the payment and to accounting to consolidate against.
The requirement in this case is two-fold: Allow accounting to see payments by fiscal year for consolidation and to change the output of the system to indicate limits by fiscal.
Their solution would have been: Semi-complicated date math that arbitrarily splits payments across fiscal year boundaries. This is roughly a full two days from a developer to implement then change all the unit tests to expect this result.
The true solution is: Add a column in a report and add a definition to the contract template. This is zero project time because reports and policy/contracting are separate departments not constrained by the project scope. Arguably the work could have already been done by now.
Requirements gathering is asking a question and getting a problem. Design is asking a question and getting a solution. Don't let people who know nothing about the system other than it's use dictate solutions.


 Obvious words, let's hope I don't loose sight of them.

Friday, April 11, 2014

Onward

As mentioned last week, I've moved past the small Rock Paper Scissors project for the moment with plans to return to it intermittently to spruce up things here and there.

As of right now, I'm still following the CodeCademy exercise guide. I'm working now on a simple address book with functions to print the entire list of contacts (two fields, first and last name, with a few other details entered but not retrieved) as well as a 'search' function, currently usable by editing a portion of the code to perform said search.

I have some mid term plans to rewrite a simple address book within Aptana. Features I intend to include are adding and removing contacts, field validation, removal of contacts and last name search.

Long term project ideas include an adaptive full data search function similar to what you'd see on many mobile devices nowdays (Hit F, we're taking you to the contacts with the last name starting with F, hit A, we're narrowing that down to Fa, etc.), contact editing and display of specific contact detail fields via checkboxes, all wrapped up in a readable and hopefully modern UI (if my idea of 'modern' isn't dated by the time I get to this).

When I am ready to start this project in Aptana, I'm looking do this from the ground up, utilizing the methods described in my 'Lets break things down a little' post.

In the even longer term, I'd like to take this outside of a local website and push / pull the data from a server via jQuery and PHP or SQL.

We'll see how it goes...

Outside of this, I'm keeping a close eye on a few reddit resources I've found a while back, /r/learnprogramming and /r/cscareerquestions focusing for now mostly on the latter as it seems to be more active and has given me insight into long term possibilities.

I find both of these subreddits great in that they get me thinking well beyond what I would be picking up on my own by simply following a track and reading materials, and perhaps even attending some college courses on the subject. This is due to the 'real world' (albeit anecdotal) experiences of many others in the industry with various skillsets, goals, education, employment history, and career paths. I'm at this point not expecting to get a lot of direct coding knowledge but rather broad ideas to keep in mind, reminders via reposts or the same questions cropping up time and time again, and a sneak peak into recruiting and the portfolio / work experience required to get a foot in the door at X company. They've also been great tools in pointing me in other directions for further reading and practice. I'd say thus far it seems pretty invaluable.

Sunday, April 6, 2014

Rock, Paper, Update.

Progress has been made. My incredibly simple and inelegant project has been a success. :) After restarting only 3, maybe 4 times. :(

 

The simplistics of how this works are as follows:

-All JavaScript is contained in a single function. The function is called when one of the buttons (top center) is clicked.
-A button onClick tag returns a unique ID of the chosen element and passes this variable into the function. This confirms the user choice.
-As previously mentioned computerChoice variable is determined by an 0.00 to 1.00 RNG. The number value is passed through an if else statement that splits the 0 to 1 value into thirds and assigns the 'computer's' choice based on which third the generated number has landed in.
-A local variable is created to convert the function id.
-The default function document.getElementById writes the player and computer input into a div tag, the winner / loser results are passed from within the if else statements described below.
-Three if else statements are created, one for each of the options the player is able to choose.
-Three more if else statements are nestled below each player choice option to compare their input versus the choice determined by the RNG.
-When the result is found, text is again set to be written via getElementById.
-A CSS style tag is applied to both div elements to apply some basic formatting for readability.

While this is an incredibly simple program, there are some design ideas and concepts at play here, namely:

-The KISS mantra. The option of allowing the user to manually input an answer (typed) into a prompt has been removed, this negates any need for excess scripting to accommodate for the what ifs of an incorrect or null response.
-The buttons also provide a cleaner layout experience. While its not much to look at now, prompts, especially on page load, are ugly and obtrusive. I'm also able to shape the design later to my liking for a much more modern (read; Less Geocities) look.

I'm not quite done with this little project just yet. I'm looking to expand on this with new 'versions' shortly. There are a few ideas I would like to implement, such as a counter for games or sets, another random element that will display a fourth option, "Magma!" This is an "I win" button for the player, but will also be added to the mix as a low percent chance choice for the computer as well. As discussed above, I'd like to beautify the experience with a modern look. After digging through some basic CSS code examples it became quite apparent I need to brush up on that. Given the simplicity of the program, I'd also like to streamline the code, although this isn't exactly a resource munching beast, there are other and likely better ways to have written this code.

And lastly, although the updates I'd like to perform are again small and seemingly simple changes, they do serve a purpose. The idea is to build good habits for revision control, assigned tasks- that is implementing one or a few new features at a time, and perhaps to punish myself a bit. I don't plan on doing these changes in an evening, but rather spread them out over the course of a few weeks, this way I can come back to the code and see a) just how easy it is to figure out where I left off (as if I'm looking at someone elses work), and b) should I fumble through new concepts along the way to; streamline the codes function and readability.

Up next, more reading, more guided tours.

Lets break things down a litte.... a little more still.

Project management. One thing I'm quickly learning is that projects big, small, or miniscule need concise logical foundations, not only to function, but to reinforce the design philosophy for that project and increase readability with a roadmap. I know there are no shortage of Project Management software solutions out there, but before I delve too deep into those, while I'm still working on the smallest of projects, I'm finding myself wanting to do the project management in my mind, or on my own as it were. That's pride talking, and pride has also had me in the position of slamming out minor changes to 'production' code until one or a few things happen; I've gone and mucked up the code beyond my own comprehension, I've made a logical error I cant wrap my head around and the product doesn't work, or worse, it DOES work, but not as expected. As I hopefully reach some form of success with the small works, and build myself up to larger projects, the hope is to have the mindset necessary to perform the following tasks:

-Dream up an idea - This seems simple enough, eh? Someday it won't be I'm sure.
-Convert that idea into writing or text - this is where the logical thinking begins, and this is where for now I begin to trip myself up.
-Mock up - The logical roadmap to the project. I'm trying to do this in my head at the moment. Not a wise idea I've found.
-Compartmentalize - Start at the beginning, build down before you begin to...
-Code! Whether this is done simply by myself or with others I expect to have a roadmap at this point, and a timeline. Tasks should be prioritized and assigned, progress should be tracked, revision history and change logging will be vital, which will lead to the ...
-Review phase slash Testing - I'm bundling these for the time being as I haven't even begun to reach this line of thinking, I will need to work on building good habits that will then allow me to review and test before...
-Deployment - Which right now consists of "File->Save / Tab to browser -> F5", and find break points. Changes come quickly and the code gets ahead of me. Pride. I need to get over my pride for wanting it to work now and focus on exactly what's happening. Take a step back. Break it down, further. Build good habits, build good code.

Oh, yeah. Code Optimization fits in there somewhere right? Right..? Again, my projects and work habits haven't even gotten me this far yet.

Self-reflection/scolding out of the way, I'll break down what I'm currently working with.

Rock. Paper. Scissors...Shoot!

I'm actively working on a humbling-ly simple Rock Paper Scissors program. It started with a CodeCademy course and blossomed into an Aptana Project. Slowly rebuilding and breaking as I've learned concepts along the way. Initially the plan was a prompt box seeking user input for rock, paper, or scissors, while another function spit out the 'computer' choice via a random number generator (0.00 - 1.00 divided into thirds and assigned an answer based on which third the number fell into), finally spitting out the results - e.g. "rock wins!" or "It was a tie!"

This grew into wanting input control and more meaningful output. So I devised a switch. It worked, sort of, if the user input a valid entry the code ran as expected and spit out some data: "You chose Rock! Computer chose Paper! Paper covers Rock. You lost this round." But what if the user input an incorrect choice the first time? It logged an incorrect choice and stopped, but what if I made it loop back to the beginning instead? What if the wrong input was given twice in a row? What if the field was null? How about if the user input a null value first, an incorrect value second, and finally the correct answer? The possibilities blossomed and I wasn't keen on all of the solutions without some major revision to the logic. Without the proper roadmap, I was quickly running into code that sort of sometimes worked, but not in every situation. Staring at a wall of code, I couldn't see the forest through the trees, I couldn't figure out WHY it did what it did in certain situations.

I was told previously when working helpdesk a good phrase that I've seen developers loose sight of:

"If you give the user a button. They're going to click it."

Why is not a factor, and it seems there is a consensus in the field that some or many developers are out of touch with the end user. I agree, I've seen it and experienced it, and already built it.

So I took a step back.

The idea of user input in the form of a prompt was put on the backburner. I'd like to explore this idea at a later time when I am better able to see the big picture before jumping into writing the code. Instead I've opted for simpler elements, three buttons that determine player choice on which was clicked. Computer choice, and the switch reside outside of the function that parses the user input. This has now caused a problem with the way logistics of how the script is executed, as the page loads, not when the button is clicked. There is also the issue of variable scope. Pride is telling me to keep plugging away, change a function, adjust the switch, DON'T look at this from a different angle, just keep going! That is until the confusion sets in.

So I've decided to take another step back...

Saturday, April 5, 2014

In the beginning...

Overview & History:

Hello, Listner (read, likely me). This blog was created and will be maintained with the purpose of documenting my personal travels of learning OOP languages. But let me step back just a moment.

It all started back in the late 90's in the days of dialup, Netscape Navigator, and an endless sea of AOL demo diskettes slash CDs. Computers were sort of funny I remember. The hardware was slow but never obsolete, the displays were 40 lbs. of visible pixels and burned-in DOOM HUDs, if you were lucky a TURBO button adorned your tower, and there was much speculation about RAM doubling software and its effectiveness. The world wide web was also a funny place. The general public didn't really understand, it was a bit of a boogey monster to say the least. It was a good age for a young man to start experimenting. I browsed some less than popular, even nefarious bulletin boards, hung out on EFNet in my spare-spare time, and my curiosity started to take over. I needed to learn what it all meant! I found a few websites of interest that I liked, not much more than your standard Geocities or Angelfire pages. Animated glitter backgrounds, <center> tags, blinking text, marquees, Times New Roman, and more. I wanted in on that. So I learned, all the bad habits and ugly design ideas. View -> Source was a good friend of mine.

Perhaps by accident I did eventually pick up basic HTML. I slowly learned how to use tables and iframes, dabbled heavily in graphic design slash (shudder) image maps, and 'trend-whored' my way through popular design styles.

Hosting was easy to find, through design favors I had gotten some amazing connections.

I begged for, borrowed, and stole images to modify, built the layouts in Notepad (I still prefer text editors to WYSWIG designers), and eventually started feeling semi-accomplished but never satisfied. When Macromedia Flash and Shockwave started gaining popularity, I thought I had piqued. I just wasn't able to grasp the concepts of building interactive bang-boom-pow-hit-you-in-the-face pages. This was the future. And I started feeling like I didn't know what an @ symbol was.

So I moved on to other languages. I went back to EFNet and started finding mIRC scripting to be enjoyable. I could write one hell of a single tiered if-then-else statement, let me tell you. I would run my head into the wall every now and again, trying to learn the basics of Flash- it never happened. In the long run I count that as a blessing. Mobile devices, Web Standards, HTML 5, security flaws, and spats with Apple have crippled Flash. Social media and cat videos have brought the internet to most. Mobile development is the new wave! I'm older and wiser now. And so with that, I am prepared to again start running my head into the wall..

Concepts:

Simply put, the overarching idea with this blog is to learn, study, write, review, and commit to memory the syntax and fundamentals of object oriented programming.

As I have found throughout the years, my motivating factor is a healthy mix of personal enjoyment, a good challenge, and those sweet, sweet "ah-ha" moments.  I have also found I can overwhelm myself, burn out, and lose interest if I'm not careful. And the last of this is the personal learning factor. There is a duality at work here, in that I know that in the near future I will hit a point in which I feel as though I need a bigger challenge, but I am unable to accommodate this desire by myself.

Expectations:

I intend to achieve my goals by several means:
-Focused learning and reading, starting with guided online tutorials and physical books. I will need to seek other sources as I move forward.
-Journaling my personal learning successes and pitfalls here. This includes noting what I am currently learning, working on, other resources, mantras, and concepts.
-Remaining active and reviewing this blog will be required to keep interest and retain information and concepts.
-Peace in knowing I will be losing sleep and hair from here on out.

Where to begin:

With this post of course. After that (so, now), I'll be making my way back to my "For Dummies" books for research and CodeCademy for practical application. My current goals are this: syntax learning via repetition, and concept learning via reading, the current language is JavaScript.