A month of Metis

By the end of today, it will have been 4 weeks since I started learning at Metis. There's a lot that I've learned, and it's impressive when I think of how now I have the fundamentals to already build something great.

If there's something that really draws me into programming, it's that sense of creation you have at your fingertips. You can code together magnificent pieces of software, like how an artisan handles his craft - this is the builder of the tech era.

At Metis, broadly the four weeks covered the following:

1. HTML/CSS
2. Ruby
3. PostgreSQL
4. Sinatra, irb
5. Ruby on Rails

Most importantly, I feel are not just knowing the tools that we have at our disposal, but also the fundamentals behind these tools, and practices that help us to be more effective and efficient. We've had to build from ground up methods in Ruby, Sinatra and Rails that are so easily simplified into one-line commands, or we've had periods of free time to come up with our own code and write a solution, and get what we want in our apps.

One huge draw is the fact that programming is like a game, or a puzzle. There's many ways to solve these puzzles, and you learn that some ways are faster than others, while others are more effective or clean to look at. There's a bit of joy when I go back to old code I've written, see what I've done, grin and rewrite what I could've done better now that I'm a month into the study.

I wrote some code for the zombie dictionary a few weeks back, now, and maybe when I go back to it it'll be significantly different by the end.

That said, over the weekends I'm slowly working on getting to know Vim, and while it more or less functions similarly between Unix and Windows systems, the fundamental differences between them will take me some time to adjust - for example, we utilize Homebrew, Vundle, Thoughtbot's RCM, and dotfiles to handle and manage packages, bundles and configuration settings for Vim. With the exception of Vundle which has its own set of installations for Windows, everything else is made for a UNIX system in mind. However, I'm learning of several softwares that emulate similarly. For homebrew, I've learned of chocolatey ; and quick searches for dotfile installers and bundlers for windows have turned up a few that I still need to go through.

Given this, an important thing that I learned is the core differences in how OSX handles its system-wide installations compared to Windows (which uses environmental variables to set PATHs), and the inner workings of the dotfiles we've been installing. Ultimately, it helps me understand what is being changed 'under the hood' when we brew a bundle or run RCM. (Most of the dotfiles change internal settings in Vim, Git, RailsVim and TMux among many others).

Like I said, there will be a part two for that, so that should be coming following further dives into converting from Sublime Text to Vim.

Rails and Resources, Part 2

The all-important table! It's crucial this week that we have most of this table down, and honestly, I wish I wrote this blog post before our weekly quiz. Definitely would've helped!

Basically, each action here is a method defined in the table_controller.rb file (in this case, wombats). The paths are defined in the routes.rb file (under resources :wombats) in their most default state. Each path functions under a particular HTTP verb protocol. Using rails, we don't have to fully type a link in HTTP, but we can use rails code (link_to or form_for) to quickly make the connections between the records within the database (via the controller, that takes in the instances of said models with the corresponding tables based on the action used) and back within our html.erb file.The instance variable objects are basically stored references to particular database segments (such as the records we're looking for in Class.find(:id)), so when we link_to the instance variable, Rails already knows what and where we're referring to.

I know one of our classmates is working on a blogpost to fully describe the actions, so I'll be leaving this blogpost short and link to hers when she's finished.

Rails and Resources, Part 1

This week, we began studying Rails. Compared to last week, I didn't run into any bumps between UNIX/Window differences thus far, so that was a relief. My PSQL is set up correctly (though I've yet to dig through security allowances and authentication more than I needed to - I'm almost sure that we'll be going through that, though), and I'm able to install rails with some ease.

This is probably the part that I had a few hiccups compared to the easy installs the UNIX terminals had, but this was all just because I didn't have all the installations ready.

Basically, I installed ruby, but not particular gems and additional devkits that were necessary to set things up for installing rails. Luckily, when I tried to install Rails, the error messages were -very- helpful (it's important to read them!) in pointing me at what I needed to do next. First, I needed to install JSON via gems, but then when I was told I couldn't install JSON via gems, they pointed me to make sure I had the devkit in my PATH if I installed it already. I don't think I installed the ruby devkit.

First things first, I needed to get the Ruby Devkit 's latest version. Once that was done, I ran the gem install command for the JSON version I needed (ruby gems will tell me what the exact version and command I needed once I tried to install rails on failure). After that, it was a simple matter of using 'gem install rails' and I was set.

Rails is fairly easy to comprehend, given that we spent the last week working with the stuff 'under the hood' - it makes all the things we did in Sinatra and PSQL so simple and straightforward, and there's lots of ways to shorten the process of pulling database entries onto a website.

Two of the most crucial things we had to consider however, was how the entire Rails system worked from request to response, and the other was the Seven Route Resources (tm?).

First, the Rails system from Request to Response: assuming the database is already made:

From the Browser, we make a Request to the App Server. It receives the path specified in the request, and properly routes it through a controller. The controller may instantiate the Model, which allows it to pull, change and request information from the database. From there, it renders the view based on what information it has and has been given, which becomes the response sent through the App Server and back to the Browser which displays the response, likely as an HTML file.

Browser refers to the user, or the browser who is navigating the html page and making the request.
The command 'rails s' boots up the App Server.

Routes refers to the routes.rb. It takes the Path of the url and accordingly performs the correct action via the controller.

Controller refers to the tablename_controller.rb. This is where the various actions are defined (akin to methods). What it exactly does depends on what Route is taken in the previous step. Primarily, it will set instance variables for the Model and View to use. It can pull/send database records/changes on request based on the Route via the Model, and render the View with the information it has before sending the response to the request back to the Browser. In the case of a redirect (HTTP code 3xx), it will not use Model or View and return the redirect response to the browser, which will initiate a new request to render the target URL.

Models refers to the modelname.rb file. When it gets instantiated, it's akin to using "tablename = Class.new". As classes in Rails in this case inherit ActiveRecord::Base, the object 'tablename' here is of type ActiveRecord and has access to the specific commands we use in Rails. Depending on what the controller requests, it may pull some information (.find, .where), pull all the information (.all), create a new entry (.new, .create) with the associated database table (which the Model is named after).

View refers to the .html.erb file. This is where the html.erb file containing all the text, code, and variable references are laid out. The Controller will read and render when it requests for it.

DB refers to the database.



====
Browser --request--> App Server --> [Rails Stack: Route --> read path --> Controller --> Proceed based on path:
====
Controller <--instantiates and requests based on routed path--> Model <--pull, change, create entries--> DB

AND/OR

Controller -- Reads based on route -->View --Rendered --> Controller --> App Server --returns response --> Browser

OR

Controller -- Receives redirect route --> App Server --returns response --> Browser
 ====

That sums up the entire process. Hopefully, this will help others understand as well. Thanks to the instructors for being patient and making this clear. Next part, I'll describe the Actions/Paths associated in the Resources in Rails.

Working with some people

I deal with quite a handful of people as moderator of an online collaborative writing group. My job is to make sure folks in the group are happy and other groups we interact with are satisfied with us. There's a couple of other things along with that to boot, but the long and the short of it is I have to speak to people within and without of my group. And sometimes, the things I have to deal with are pretty outlandish.

I've written a general post that more or less sums up a gist of the issue:

"When you're in common society, you're faced with several choices. Among these choices is to avoid getting stigmatized as a result of your own actions. Maybe it was an accident, or maybe a cause of ignorance, or maybe you just didn't care, but you end up branded with negative labels.

Keeping that in mind, when you attach a stigma to someone yourself, you're part of the problem. It's even MORE depressing to see that stigma spread and persist for years without looking at that person a second time and keeping your head down (or nose up, depending on what kind of stigma you're attaching). What's MOST depressing is to see that when you yourself are pointed out to be part of the problem for not doing something sooner and just covering your ears, your response is to be irresponsible and deflect, ignore, play the victim and say that the person with the stigma deserves it for their actions. No matter how many times you get acknowledgement that the stimga-ee (is that even a word?) is indeed at fault, you will not take the part-blame for perpetuating the problem. By not seeing how your past years of loathing of the person for whatever reason has prevented you from being unbiased in your approaches, you failed to cut the problem when it was relevant. At the time, you felt that it was best you deal with the issue yourself - but what did you do exactly? And what was the result of that? If you're unhappy with your inaction, you end up blaming the stigmatized - yes, the one you attached yourself and continued to spread it among other people.

But that's human beings for you right there. :P But moral of the story, avoid the stigma, but don't label and perpetuate it. And don't let other people paint the stigma for you. For the love of God and the universe, don't let other people paint your perceptions of a person or party."

Coding on Windows in a UNIX-heavy class, Part 1

Part 1 because I am sure I'll be writing more about this down the line.

Most of the class in Metis is taught using Mac OSX. I've quickly learned that many and most programmers use Mac OSX, LINUX and other unix platforms (at least, among those I've seen in my stay in Boston). Developing on Windows is pretty unpopular - this much I've been told by people I've spoken to.

I've been loaned a mac prepared and ready for use by Metis, as I've brought my Windows 7 laptop along to the course (most of those in the course and the instructors are most familiar and are using Macbooks). I'm familiar with Macs, I've used them every now and then in University, but I was born and raised on Windows. Feeling like I can keep up despite the OS differences, I decide to stay on the Windows while bringing the Mac with me just in case it proves too much.

Week 1, there wasn't much of a difference. Week 2, we've begun work on SQL, ruby gems, multiple ruby versions, etc. and there are tons of UNIX specific programs and commands that my Windows didn't have. Being the only windows user in the class, the pressure was high for me to just boot up the Mac - but I decided to keep pressing on. It required a lot of googling during the lecture itself, and even making sure I was ready before the classes even start.The instructors are able to help if I asked though (the godsend of having 2 at once), but I feel like that I should be able to overcome any issues from my choice on my own.

I have to say: it was a little nervewracking, but it's a feeling I'll have to get used to. I have to make sure I could catch what was being taught in the lectures while at the same time searching for many solutions to whatever thing I needed to do. Once I was on the same page, there was a terse feeling of relief - I wasn't sure when the next time the software would do something unexpected from what was explained and I had to fix it up myself.

Summing up what was taught in the last few days - I'll write a more detailed post later - but we started the week with PostgreSQL. I first installed PSQL with the following links' assistance. It's important to make sure it works and verify that it works on pgAdminIII (easiest way to check. The instructions make it clear):

PostgreSQL for Windows
PostgreSQL Installation tutorial

Once it works out, PSQL should work on your command prompt. You can open git or cmd (I'll set up Vim later in the week) and type:

psql


Now, when I type it out, it asks me for a password (which you establish when you first install psql). However, when I enter anything, it says I've given a wrong password for my user. I think this has to do with the installer I use (hours of googling reveal that not everyone can face this issue) and certainly the others in the class didn't have this problem. So what happened?

Either it was some sort of PC configuration or just how I installed it, the PSQL user profile postgres isn't the default one set when using the psql command in prompt or git - thus it defaults to inputting my computer user profile as the one accessing the psql command. That's not exactly what I want, so I have to specify who's using it (using the installed PSQL shell that came in with the PSQL installation though, by default uses the postgres superuser for accessing the database). The --help command, that is:

psql --help

Is immensely useful because it lists all the other commands and arguments you can attach to psql. So, to access psql, I can use

 psql -U postgres

 in command prompt/git, will let me specify the username to postgres. Then, it will ask me for a password, after putting it in I will have access to the database. By default, the database is postgres - so if I made a new database photo-gallery I have to specify the database:  

psql photo-gallery -U postgres 

One password input later, I'm in the photo-gallery database. That's great and all, though it gets annoying every time to input the user name and password (and in one instance using psql, I found that my password input isn't masked, which is a huge gasp. I've googled for fixes and ways to simplify the process to make it similar to how the Macs seem to have no issue entering/exiting/doing postgres commands, and there's a few suggestions. I'll get more indepth once I commit to a choice on how in another post, but these are the gist of the solutions:

 -Make an alias that automatically inputs the username postgres each time
-Edit the authentication process for users that aren't postgres as well as password input
-Just use a linux-emulator (I'll describe this later)
 -Adjust a configuration 

Again, maybe it's just how my computer is set up, but none of those are straight forward. The other issue is, when you google for a solution, 80% of the solutions, if I don't specify for it, are for OSX/Linux/Ubuntu, not for Windows OS. Another issue is, there are 4-5 different answers on stackoverflow (a godsend of a resource next to programming documentation), but most of them aren't really much in the way of instructions (they assume you know your stuff most of the time,) so you google for particular things in those instructions and so on until you get what you want. Making aliases on git,the way its set up for me doesn't seem to work (I'll be googling to find where the config file it loads from is located) because there seems to be 2-3 different config files (according to the results I'm getting at stack overflow).

Similarly with psql. There's many ways to fix the issue in adjusting configuration, it seems, which is nice and all - though all of them seem to carry some kind of security concern - which is probably much clearer the more I learn about databases, how remote connections connect to my database, etc will allay any fears I have (Hence, why this is part 1). There's neat blogs and pages that explain the important types of security authentication for databases that I'll be reading into for when I get in-depth.

That said, I found a nifty little blog by someone familiar with the installer I used that explains a little about this issue on psql via EnterpriseDB: Dave's Postgres Blog

But enough about psql; there are other things that I had to do googles for mid-lecture and that was for a way to change ruby versions that are installed on your computer. For Mac OSX, they used Chruby and rvm; for Windows, I found pik.

Pik mimics a lot of commands that rvm and chruby does - we haven't used it substantially, but I have it ready (and it's important to make sure it is). By default, when installed pik only works on command prompt, not git; and it goes back to finnagling one of the config files for git to get pik commands to work on it.

While it is possible to install pik using ruby gems, I did an install through the .msi file on pik's GitHub page. Again, it might be with how I installed my ruby (I installed x64 version of Ruby 2.0.0, but installing pik via the gem only gave me pik 0.2.8 whereas the latest version was 0.3), but at the end of the day, I had to edit my %PATH% environment variables to make sure pik properly worked. It's important to understand Environment_Variables on windows and making sure I knew my %PATH% and what it does so I can be sure that things can work (it's crucial in trying to make sure your PC functions when you install new programs through prompt, etc.)

I'll probably touch on pik and %PATH% a lot more when we actually start using rvm/chruby in class, however. But I got mine working to a point where I can change ruby versions.

That's about it for this post; however there are some very crucial pages I'm keeping tabs on. The first is a page for Windows and Unix equivalents ! It's pretty important. There's several terminal commands on UNIX based consoles referenced in class which are essentially synonyms for what Windows uses. It's a good cheat sheet to have and look through. The other is a linux emulator, Cygwin . I came across this while searching for ways to change ruby versions on windows and a post described using Cygwin to use rvm on a windows PC. I didn't really read into it, but it'll be a good thing to turn to in case I ever find something on UNIX that is not yet replicable in a Windows environment.

Revisiting the past

I mentioned in the last post that I really started reading code (Ruby, anyway) through RPG Maker XP, or RMXP for short. The programs that followed, developed also by Enterbrain was RMVX and RMVXA (RPG Maker VX and VX Ace). Today, I decided to spend a short while in the afternoon to revisit that.

Lo and behold, a script among many others from the software default library:

#==============================================================================
# ** Scene_Save
#------------------------------------------------------------------------------
#  This class performs save screen processing. 
#==============================================================================

class Scene_Save < Scene_File
  #--------------------------------------------------------------------------
  # * Get Help Window Text
  #--------------------------------------------------------------------------
  def help_window_text
    Vocab::SaveMessage
  end
  #--------------------------------------------------------------------------
  # * Get File Index to Select First
  #--------------------------------------------------------------------------
  def first_savefile_index
    DataManager.last_savefile_index
  end
  #--------------------------------------------------------------------------
  # * Confirm Save File
  #--------------------------------------------------------------------------
  def on_savefile_ok
    super
    if DataManager.save_game(@index)
      on_save_success
    else
      Sound.play_buzzer
    end
  end
  #--------------------------------------------------------------------------
  # * Processing When Save Is Successful
  #--------------------------------------------------------------------------
  def on_save_success
    Sound.play_save
    return_scene
  end
end

Just earlier in the year, these words made very little sense to me. I used to just try and piece things together where I can and if I need to modify something, more often than not it's on a custom-made script by other programmers (who upload a free-use script for use in RPG Maker or sometimes commercial license required scripts) and they use Constants (Now I know the right term!) that users of the scripts are allowed to adjust according to the users' needs. But now, I can read the meat of the scripts very well!

Essentially, Scenes in RGSS (the name of RPG Maker's library for ruby) refer to windows that players will be seeing in the game - which are classes. In this case, Scene_Save refers to the save game screen when players want to save their game. And now, I can break this down bit by bit.

Scene_Save is a class, and it inherits Scene_File class (Makes sense, because Scene_File, a much bigger script handles the write/load procedure of saving and loading games, which its subclasses (Scene_Load, Scene_Save) will use.As a class, Scene_Save will have many methods inside it - and now I see that there are many methods("help_window_text", "on_savefile_ok") and constants being called within those methods itself. And knowing the software as long as I have, I know what those constants refer to! This particular script now makes tons of sense.

In the past week, I've been wondering why when we learned reading/writing files we used one script that had the class handling the read/write method and another script that actually called the methods - but seeing them in action in RMVXA really made it that much clearer why they'd do that. It's cleaner, easier to see - far better than putting everything on one script. It's also because in this instance we have 3 different windows that the user will interact with in the game, which is the File Scene/Window, which asks them if they want to Save/Load so they can make a choice if they want to open either of those scenes. Then, Scene_File handles most of the read/write processes while Scene_Save/Scene_Load just creates the windows for user interaction. It's important because if we want to override any of these with a custom script, it's so much easier to just override the class Scene_Save and Scene_Load (Which custom Save/Load mods DO target if they just want to change the general layout) or Scene_File (where they change -how- games are saved and loaded, such as directory, information actually recorded, etc.).

I look forward to actually using the built-in scripts as well as custom scripts to further learn as a case study for Ruby scripts in the future.

Friday Challenge - ZOMBIES!

Today at Metis is a friday, and fridays are basically 'do whatever you want days'.

For me, this is fixing up the blog, and doing a few of our programming challenges. We also had a talk by Ben Orenstein about the things we as budding programmers should consider for our future. Very informative, very helpful!

So: the programming challenges vary in difficulty. Some are fairly easy (such as summing up all fibonacci numbers up to 4 million):

class Fibonacci
 def initialize
  @num_interim = 0
  @total_sum = 0
  @num_1 = 1
  @num_2 = 2
 end

 def fib_sequence(limit)

  until @num_interim >= limit
   @num_interim = @num_1 + @num_2
   @num_1 = @num_2
   @num_2 = @num_interim
   seq_check
  end
  puts @total_sum
 end
 
 def seq_check
  if @num_interim % 2 == 0
   @total_sum += @num_interim
  end
 end
end 

wombat = Fibonacci.new
wombat.fib_sequence(4000000) 

But even with how I managed to get what I needed, I'm positive there's better ways to write that code. That's part of what we're taught at Metis - the importance of refactoring and keeping code clean and easy to read.

That said, the real difficulty comes in the form of this particular challenge. In short, it's trying to make sense of what seems like plain gibberish (zombie speech, according to the scenario), by loading up various scenarios that contain a dictionary and looking up zombie garble to check if the words are a match, then suggest if that was what the zombie was implying. We had an input file, with a few numbers, then a list of words, then a number, then a list of words, and so on for the rest of the number of scenarios. The numbers either described the number of scenarios, the number of the words that would come after the number, and the number of zombie garble that would come after it. It's a bit of a confusing file to read at the start.

Here's a snippet of what was 4 hours of work:

 def read_file
  File.open("./zombies.in", "r") do |file|
   #get number of scenarios
   @input_file = file.readlines
   set_scenario_number
   until @current_scenario == @scenario
    if @word_number == 0 
     set_number_words
    elsif @garble_number == 0
     set_number_garble
    else
     next_scenario
    end
    puts "Currentline is now #{@currentline}"
   end
  end
 end

It had a LOT of forms before it came to this. All this ends up doing is loading up words in each scenario, shoving it into specific variables in a specified order (The .zombies.in file is written in such a way that this is necessary, part of the challenge) so I had to create a loop to make sure I got every word in the dictionary and every zombie garble into a list for each scenario before it moves on to the next one.

It hasn't done any of the features it needs to after the fact, but for now it was VERY satisfying to see it run after awhile. A few things that I learned:

The .readlines command - incredibly helpful because it turns your entire file into an array of strings. Now, the array had some strings that contained some numbers, which posed issues unless I knew exactly when the numbers would come (so I can safely predict and use .to_i - which I did!). You can't call .times on these strings without calling .to_i. And initially I used .is_a? Integer to check what type of element the current line was reading, but when the loop failed, that's when I found out .readlines returns an array of strings.

So, in short, integers are really wonky and hard to work with when they're already strings, so you have to be very creative. X.x

Here's to hoping tomorrow I can finish the rest of the program!

This is Metis

Last post I said what a crazy week it's been, this week is still crazy.

So I'm part of Metis, a ruby-on-rails webdev/programming bootcamp. I didn't know what to expect when I first put in my application months ago; someone had recommended to me following my degree I try programming, and then I got forwarded the application website.

That's what started this entire trip, and now I'm in Boston, MA. This is my 2nd week in the States, and I've just gone through the first week of classes.

I'm not new to programming. I think my earliest programming history -truly- started when I fiddled around with my computer's ins and outs. The idea was that I understood how a computer would think. I started modding games, understanding the ways how programs, or maybe even just how windows parses information. Very simple, very outside stuff, no real coding yet.

Then I started to play with my first 'code', which is event-based scripting in RPG Maker 2000. It was a program of sorts, easy to use, intuitive UI. Confusing at first, but to simplify the software to those who aren't familiar with it, it essentially lets you script out processes in an old-school-esque game (2D, top down, sprite RPGs) on events (which are kind of like objects), using predefined methods (such as moving the event, opening a chat box on interacting with the event in game, altering game parameters such as character levels or items after interacting) that can be chained in a sequence. This is essentially programming - sequencing a bunch of code to make something happen.

It's in a nice little package, but several RPG Makers later till RMXP, I've been fiddling on and off, trying out freely available games on the web, editing them and adding onto them as I saw fit, playing with the tools, creating my own projects and expressing my (then-very-cheesy-plots-based) creativity. I even beta-tested and contributed to Solest Games' Master of the Wind - a huge project that was 7 years in the making by 2 guys; and even today I am helping where I can with their latest venture (after they had just released another game commercially on Steam). Using the maker's built in RGSS system which is based on Ruby, people can significantly alter the games with scripts that override the default systems or even create new systems. I didn't code too much but this was when I started reading parameters and elements, and changing a few things where I could to fit custom-scripts made by people to my needs for any sandbox game I was trying out or debugging.

Following and around this I looked into modding Bethesda Games' Fallout and The Elder Scrolls games, and debugging is a huge process for anyone trying to load 100+ mods into their game. When TESV: Skyrim's Creation Kit came out in 2011/2012, I jumped on the ship and tried to make my functioning, but incomplete mod during University. The CK used Papyrus, which I believe is a modified version of Java or JavaScript. It was probably the first time I seriously tried to write real code - and as clunky of a software as it was, there were many good 'eureka' moments when something went right. I really enjoyed spending nights coding instead of actually studying when I was on a high - it felt good to create something.

That summed up the programming experience I had, besides coding few scripts and lines in R and SAS for statistics analysis in University for my science degrees (By that point, code syntax had become pretty familiar to me, no matter the language). Months after the application, a few codeacademy lessons later, I've finally arrived to the course.

The first week was -great-. It's a small class, less than 15 people, with 2 fantastic and patient instructors. The course is aimed at people with little to no background in programming, and while I feel that I and a few others have a bit of a leg up in the first week, I think everyone else is catching up to where I am. Even though I think I grasped everything fairly well, I still make mistakes, and I still get baffled by programming challenges - which is fair, considering how I've never done any kind of proper code. I -can- write some code, but the cool thing at Metis is how they teach me how to do things efficiently and properly, which is really important in the world where things are mostly open-source and people code together.

It's a fantastic place to be, and week 1 is coming to a close. I'll be putting up some code on some of the challenges I've bee doing, including the challenges I've been facing. Here's to a good 12 weeks!

Settling

What a crazy week it has been.

I flew to the States for the first time, and I arrived in Utah. After a 34 hour travel time total, most of it spent in the sky, I was picked up by the admin of our writer group. It was late at night, and there was nothing more to see except a well earned rest with his lovely parents. Then, a few days after, it was going to be a trip of a lifetime.

Out of some 20-odd number of people, 9 from our writer's group congregated in the state from all over the US and one from Canada for a camping trip. It was the first time I've met these people in person - not just voice or video over the net. There's been nothing short of miraculous adventures since we set out. I don't know what was more amazing - the beautiful sights of the red, white and sunset canyons north of Salt Lake City dotted with marvellous green forests, or the fact you spent 2 years to build a wonderful relationship with these fantastic writers that became a circle of inspiration, talent and personalities on a foundation of friendship culminating in a physical meeting.

The trip was a series of firsts - mostly those where I did things I never thought I was capable of, being surrounded by inspirational and good people that edged me to be truly myself. On the inside, I was an adventurer, a person who enjoyed hardships, trials, fascinating new experiences. And never before did that spark to its brightest before this meeting. Rock climbing, camping, spelunking, hiking, exploring, a road-trip - all in all, it was a fantastic time, and I came back from it much more inspired and motivated for more.

I grew up on the internet, and if I had to consider my web history, it's a small wonder why most of everyone I know, trust and care about are in the States.

One way or another, I want to settle here.