JS frameworks in SF

These past few weeks have been extremely busy and challenging without a place to live but luckily I am now secure in a place and stable enough to writing blog post on the regular.

I have had the opportunity since arriving in the city of San Francisco to attend a number of meetups and training Sessions.

Ember:
I have been partial to Ember for the reason that I felt like focusing on one framework first prior to branching out, the main reason I chose Ember is because I actually personally knew people who used Ember in projects and could ask them questions. Even with Angular being a larger community; I just did not have an opportunity to meet any of them prior to starting my first frontend project.

Ember has a very impressive community in SF, and I had the opportunity to attend my first EmberSF and was very impressed with the caliber of talent that attended the event. I am still very pro Ember but like the fact of peeking/using other frameworks at different times.

Ember is great for teams because of its structure, no matter what Ember project you can, similar to Rails, know where important components are located and understand the basic structure.  This reason is due to the "Ember Way" of doing things is generally the same across the board. A

Another nice thing about Ember is they had an early adoption of ES6, which actually has helped me in understanding other frameworks like React and even the differences between node and io.js. There is a lot cool things happening with ES6 and I had the opportunity to learn it through Ember even while being very new to Javascript development.

Some things I am finding challenging with Ember is finding the libraries that match the newest way of package management with ember-cli. I know there is a ton of libraries out there but just not a ton of documentation due to "newness" of everything. With that being said, I am excited at the opportunity contributing to the community in that way while I discover different better practices.

Angular:
When I took the job at Bloc, I was made aware of the use of Angular in the project and began researching Angular right after I accepted the position. Probably due to my love for Ember, I did not find the excitement in learning Angular, as much I did with Ember. I however attended an all-day Intro-To-Angular workshop the second weekend I was in SF.

Now that I have gotten past the initial beginner phase with Angular, I have come to appreciate the stability of Angular and how has fast it is to get up and running in a project. Ember is big into separating the API from the concerns of the frontend framework, but Angular seems separate but still knowledgeable about everything.

In a conversation I had with neighbor while pairing at the event, Angular is still new to developing best practices in creating an app and it has been a struggle to newer devs to Angular. I believe things will be getting better when Angular 2.0 is rolled out and I have heard word that there will be a planned upgrade path for those on Angular 1.x, which is contrary to what was announce last year - which is good.

I do have to say it is nice knowing how to use a framework as popular as Angular and being able to contribute to the JS framework conversations. I also think it will take a lot to unseat Angular as the leader in the framework battler for the simple reason that chaos of how customizable Angular is probably one of its strengths. Ember has a lot of the conventional ideas of Rails and some of it own and it does not seem conducive for a non-ruby/ post-ruby dev to learn these conventions. If someone writes PHP or JAVA in a way and wants to apply Angular to a project, they can with their own special conventions.

I think the next year of Angular will be pretty interesting and I am appreciative that I know a bit of it and have gotten up to speed enough to be able to work with it on a day to day basis.

React

React is definitely a framework I have hardly any experience with but I did attend a react meetup last night and very impressive with what it can do. I do know some of the React creators were big Ember evangelist at one time and saw many similarities to Ember in the React 101 talk last night. I am definitely impressed with the speed of React and what it does on the View layer, but the idea of calling a "framework" doesn't seem right.

The React core team addresses the product as a "library",  which I will from now on. React actually should be thought of as a jQuery replacement tool. It does a lot of work to speed the rendering of your views and like the full-service frameworks react only needs your api, regardless of what language it is written in.

The other portion that makes React be considered a framework is Flux, a separate project that helps with data stores. When you receive an object from a JSON API (one of many options) the framework/library grabs the data and stores that object and attaches "observes" to watch for any changes to update. Flux is very similar to Ember-Data and js-data, actually js-data copies a lot of what Ember-Data does and Flux has a lot of similarities Ember-Data as well.

I envision that Flux and React to become synonymous with each other in the future to make that "framework" everyone is looking for. I have plans to actually start a React project soon and even take a chance React-Native with that same project, but per the presenters comments there are a lot of things to left to be desired in React as they continue to iterate on this new product.

Conclusion:
There is actually a lot to be desired in all the frameworks and in reality, I don't any framework will ever solve every known problem.  

As soon as I wrote about my experiences with Ember last summer I received a lot of feedback on why I did not choose Angular and I did not have a great answer other than fact that I didn't know any Angularist I could get feedback from. I understand there is a "Holy War" going on right now about which Javascript frameworks is the best, but that is dumb.

My recommendation is to pick one framework and learn it and don't be afraid to branch out to learn from other frameworks, because at the end of the day its all still Javascript.

P.S. I hear Meteor is by far one of the easiest to learn and though it was not mentioned here, I highly recommend reading up on that one too.

Are programming bootcamps worth the price?

The past week has been very busy and included two trips to move my stuff from Orlando to Tampa to prepare to eventually move to San Francisco. While picking up my uhaul the Uhaul employee noticed a shirt I was wearing which happened to have the logo for Extreme Networks, a vendor I worked with at Tech Data (in sales). I explained it was a networking company and he mentioned that he was looking into going back to school for networking engineering and asked me if it would be worth it.

The individual was probably around my age and I asked him why he wanted to do network engineering? He explain that it probably paid well and he was always interested in computers, and with my keen ear for hearing the customer and closing a sale I just had mention my story and how I got into software in less than 7 months. 

He was definitely intrigued and I told him about my new employer and how we teach interested individuals how to become a web/mobile developer.

This got me thinking while I drove across the state of Florida, this uhaul employee was going to go back to school for probably 15-30k in tuition for the hope in making more than what he was getting paid at Uhaul. I paid 5k for the opportunity to learn via Bloc and in person bootcamps for less the tuition and dedicated 4 years. 

While at IZEA I watched countless interviewees walk in for interviews out of college with Computer Science degrees but no real experience and no real portfolio to prove their ability develop code. 

In the United States it is preached that once you have a degree you will have a great job, but I worked at a job out of college for 24k a year because I couldn't get a job in finance.

So my question before I answer original question is, Is getting a college degree even worth it? I have Finance Degree from an accredited state school and have yet to use that piece of paper or even provided a copy of it to any of my employers. To be honest I haven't even removed it from the cardboard envelope it came 7 years ago (What a waste of $48, the cost to send it to me).

I now work at a job making more than twice as much as I my base pay in sales and a significant amount higher than my salary even with a highest received bonus'd month. When I share the amount I paid to learn via Bloc's mentorship program and discuss the cost of bootcamps with others, it is very common to hear that rebuttals to how expensive the cost is, but when you talk with the same population of people  about going back to school, there is not even a second thought about that cost. 

For some perspective: I am currently rooming with someone who made the decision to drop out of a very well known and expensive College in Nashville to pursue his dream with DevBootcampSF, which really sparked me to write this blog post. Instead of paying for 150k+  in tuition after graduation, he is now only what it would cost for one semester in College.

So are bootcamps worth it?

My response is obvious, it yes, but I truly believe if you are looking for an experience that you get when going back to school where you can just breeze by and get a job when its over, you might as well just go back to school. Bootcamps are definitely worth it, but you need to be driven and be willing to experiment with different tools, build a portfolio outside the curriculum, and be willing to attend meetups get involved in the community to eventual get that offer that truly makes it worth, but more on those details in a future post. 

Bootcamps, including Bloc, all have payment plans to help cover the cost up front. Some bootcamps even offer financial assistance for the exceptionally driven individuals.

Best of luck on your journey and your decision to learn to code. 

Middleman Blog in store

I finally completed a Middleman Blog from start to sort of finish. Middleman is an easy to use framework for building static sites. I have been in the need of transferring this blog elsewhere but do not want to get stuck in the rut of building a ship while you use.

My fear was always getting too involved in the process of building the blog and never writing blog post. That is why I am happy to start hosting my podcast there at first. FYI, developingstory.link is my middleman site.

I was actually able to get it started rather quickly using the middleman and middleman-blog gems.

Once the blog was set up I had no problem creating my first post and setting the bootstrap (yes I did it) template. The challenge will be migrating the post from here to the new site, but I am holding off until I am confident I won't be working on the bike shed color rather than writing post.

- I will definitely be looking forward to add syntax highlighted code samples to the blog.

Thanks for reading and checking out the podcast. The plan is to have episodes out every Friday, so look for the next one this week.

In the meantime checkout Middleman and checkout fellow a Ruby Newbie, Colby's, impressive Middleman blog

I made a podcast

I made a podcast over the weekend, something I have wanted to do for awhile. The podcast itself will just be me, no interviews, chatting about my story into developing. I have completed about 16 months in learning myself and with a mentor, with 9 months of that working professionally.

I am now embarking on a new journey and felt as if a podcast would be a goo platform for that. I am still continuing to blog on my coding discoveries here, but will eventually move it over to my new site.

Please check it on at DevelopStory.link

I had a go with GO

This past months has been full of me trying new technologies, not only with Ember but I also had a chance to try out GO. Thanks to the connections made with Steamrolers.com I was able to connect with a prominent GO developer and they were able to give me recommendations on tutorials to get an understanding of GO.

My goal for 2015 was to try out some lower level programming languages as well as some functional ones. My eyes have been on GO and Rust for awhile, but do to some unforeseen circumstances I was unable attend a CodeNewbie Code Club event on Rust. I did however complete a Tour in GO and got a very high level understanding of it.

GO basially reminds of C, not that I had much experience with it, but I did do some C work while completing the Havard CS50x course last year.

Some issues I had with GO was forgetting the "returns," With GO being a low level you have explicit call return in the functions as well as handle your own garbage collection. Ruby does so much for you and makes it very nice, especially when learning to program for the first time.

I successfully submitted some code exercism which I will not share in efforts to not give away the answer to the Leap Year kata in GO, but I have to say it was quite challenging passing my first test in GO.

Package management is also handle by you, and I made the mistake of setting my project package to "main," but had the test package as "leap." This took me awhile to figure, but once I did one test passed.

I then had the trouble trying to figure out to return interpolated strings with my Leap Year integer but later found that was unnecessary within the scope of the test, I only needed return the integer, because ethe test was already returning the string for me.

Altogether my experience was ok, but it has wet my appetite enough to want to see this through. I originally installed GO via homebrew, which I also found out that was a big NO! Only because some things that I have heard that there are a few things to be desired once you really get in to GO and homebrew does not provide everything. So while attempting to install GO the right way, I came across too many errors and currently taking a sanity break until I decide give it another go.

If you are learning GO or experienced in GO and would like to pair on my installation process, please reach out.

Thanks for reading and happy hacking!

Deploying my first Ember App

For every Rails app I have created and thought about creating I have used Heroku. I have never had a need to use anything else, as none of the apps I have developed had users and needed to grow beyond the same place of Heroku.

It is very apparent that Heroku has cornered the market on new Rails apps and most people I know don't think twice about running `heroku create <my-app-name>`, especially with the recent announcement from ninefold and their closing down their Rails service.

When it came time to deploy my first ember app I automatically assumed I would use Heroku, since I already had the Rails api waiting in a heroku dyno. Literally the day before I deployed my app I heard a coworker mention how another company in the Orlando area deployed their ember app to a lesser know company, Divshot.

I wasn't aware of their service to deploy static web pages, and also was aware of an ember-cli addon that makes deploying to their service so easily. I had some issues that with getting my rails api url to get included in the config, but once I got that figured out it was a breeze to deploy. The deployment was actually so easy that I have completely discounted the need for heroku and might even transition some of my more popular static pages to the Divshot service.

If you are looking into publishing your first ember app, I highly recommend giving Divshot a try and using the ember-cli-addon.

First Ember app complete...sort of

I spent some time in Ember tutorials and had plans to have an Ember project built and launch back in January, but some unfortunate life events got in the way.

I am now proud to announce that I have completed my goal of getting an Ember app built and launched in 2015. The app itself if very much in an MVP state and I am looking forward to finish the other features I have planned.

Some of my experiences while working Ember how impressingly fast it is to build a Rails API when you aren't concerned with the asset pipeline or views. Ruby is a great server side language and fast enough for me, but sometimes Rails can be a little much; I highly recommend reading my blog post on the Rails API gem, which makes building an api a breeze.

Most people I have spoken with get hung up with the fact that Ember is constantly changing, which developed a very steep learning curve for learning it. I personally completed the Vic Ramon, Treehouse, ember-cli-101 resources and found them to be enough understand the basics in Ember.

I also spent some time learning form the forms and docs, as wells as attended EmberOrlando a few times.

I was basically at a point where I needed to start an Ember project and start learning things outside a tutorial, which I found to be challenging but obtainable.

My first hiccup came when I tried to connect my sample fixture data. The solution was rather easy and actually kind of silly how simple it was.

My next hurdle actually came when deploying the application to Divshot. I normaly use heroku as my go to deployment vehicle, but heard of the great tools available for ember and more specifically ember-cli. The solution for this was not as simple but I figured it out with help from @robdel12 and @jgwhite.

Takeaways:

Now that I have finally moved into world of modern day "Full Stack Developing", I am exited at the idea of separating the concerns of the api and client-side. This will give me the ability to one day try out the ever so popular React.js or even use the api data to produce an iOS app.

I highly recommend everyone who has been in rails with their head down while Front-end frameworks have been popping like rabbits.

I plan on doing more detail post into Ember and its structure in the future, but if I could recommend one tutorial to get started, it would be the ember-cli-101 book. Its the most up to date and gives you a great understand to how Ember works. It also provides the generator commands similar to Rails, that will help you get started much faster.

If you would like to view the app live, its temporary home is here and will the code is here.