All Ruby Podcasts by Devchat.tv

My Ruby Story Dave Kimura

On this episode Charles talks to Ruby Rouges panelist Dave Kimura, the creator of Drifting Ruby, the popular Ruby on Rails Screencast and Blog. Find out more about how Dave got interested in programming and first introduced to the world of Ruby. Dave also talks about how and when he started Drifting Ruby.

How did you get into programming?

Dave discusses living in Germany during middle school in the 90s. During this time, he owned a simple Mac LC II. He found a floppy disc that contained a program called Chipmunk Basic, which was his very first exposure into the world of programming. His interest with programming was further sparked by computers at school. These computers were loaded with three different programs: Fortran, Pascal, and C compiler. All of these peaked his interest in programming further.  


Charles and Dave discuss the impact technology made. 

Dave tells Charles that anything that pre-dates the Internet feels like a different world; one in which learning was more complicated. He talks about how technology has come a long way in the past 20 years. He discusses the creativity that people have displayed and how amazed he is by the progression of different applications.

How did you make the transition from different programs such as PHP and ActionScript into Ruby?

Dave discusses his work as a Systems Administrator at an engineering firm for the past 6 years after college. He talks about being at his current job at Sage Software for almost 8 years and that he does not believe in job hopping, although many do today. He states that he has no valid reasoning that he went with Ruby over Python or another program. He says that he did not like PHP or asp.net. Instead he wanted something new. Dave wanted to do things the way he wanted to do, which can’t be done in Python. A big part of his decision was made when he looked at Matz’s twitter. Matz seemed happy which led Dave to pick Ruby, which he thinks is mainly a good “dumb luck” decision.

What kinds of things have you done with Ruby?

Dave says that the coolest thing he’s done is with a Raspberry Pi his brother gifted him in 2013–2014 for Christmas. He built a CNC machine and a Ruby Gem called a Router out of it. He explains that he wrote an interpreter to read and control the machine. He adds that he has built a bunch of hardware as well.

How did Drifting Ruby come about?

Dave says that his inspiration is Ryan Bates, who created RailsCast and went off the grid in 2013. He strives to fill in the high bar that Ryan left by producing quality material.

When did you start Drifting Ruby?

Dave started Drifting Ruby in 2015, which is a couple years after RailsCast. He explains that he was not entirely committed to the program at first. He explains that he has revamped the audio setup two or three times.

So where are you hoping to get to with it? Are you just trying to put good content out or monetize as well?

Dave is currently focused on releasing good content. He wants to give back to the Ruby community and feels good that people are able to use the content he produces. Eventually he states that it will go to a subscription base, but does not have a definite date as to when. He is very dedicated to his work, as he spends 10 to 15 hours of his weekend working on episodes.

Are there things that you feel that you have contributed to the Ruby community? 

Dave feels like his commitment to Ruby Rogues has been consistent but is not a hassle. He doesn’t look at it as something he wants to get paid for because he enjoys the time he dedicates weekly. He doesn’t feel like he’s had anything big other than Drifting Ruby.

So what are you working on now?

Dave is currently working on a money manager that he uses with his wife. He built this Ruby on Rails application in 2011–2012 off of the premise he learned at a Dave Ramsey conference. He states that he recently rewrote it and cleaned up so that it uses the latest Rails 5.1.1. The application helps budget money for bills, groceries, spending money, etc. using a digital envelope system. He states that anyone is able to use the program, and it has made a difference in his life.

Picks Dave

Harbor Freight

Charles

Ketogenic diet Spaghetti Squash

Links

Dave’s Twitter
Drfting Ruby Twitter
Drifting Ruby

My Ruby Story 009 Brian Hogan

On this episode we have another My Ruby Story and there is a good chance you might recognize him, he is one of Devchat.tv’s panelists Brian Hogan. Aside from being a panelists on Ruby Rouges, he also has a couple other projects like codecaster.io as well as Railsmentors.org.

How did you get into programming?

Brain talks about how his Dad has an old Apple 2 computer. His father was a teacher for the blind and the computer had a box on it that would talk. His Dad taught him that computers can have programs written for them and make them do things. Brain talks about having math issues one evening and his Dad helped by making a math program that would quiz him. His Dad wasn’t a programmer but he had picked up some of it from being around it. Brain talks about how the library had games you could get for the Apple 2 but you had to write code into the computer to make it work. He started tweaking the code to learn that it adjusted things in the game like the speed of the spaceship or the damage of the bomb.

Brian’s First Program

Brian’s first program was in fourth grade. He had an assignment on the topic of the seas and instead of doing a typical handwritten assignment he created a program for it. He learned that he could make the computer do things. Over time Brian got interested in other things, planning to go to school for law. His Dad lost his job making his plans for law school unreachable without student loan debt. He started making money on the side repairing and building computers.

Computers solving problems

He talks about how he never really got into the computer science level of things, but he was always excited about being able to solve people’s problems with computers. He remembers getting internet for the first time. It was Netscape and it came with a book on how to setup the internet and then in the last chapter it had a section teaching how to make a webpage with HTML. He loved making websites and so he made pages for businesses and made money on the side. He went to college aiming for computer science and then when he got into classes like computational theory, he found that it was boring to him still. He changed his major to business. He then got a job working for the college working with website stuff. The developer for the pages ended up quitting and so they asked Brian to help out. So he learned Microsoft server SQL and ASP. He adds that essentially he fell into web development by accident. He talks about his code being bad until he learned Ruby, crediting Ruby with making object oriented programming easier to understand. Charles mentions that he felt the same way in school, it wasn’t until he needed to fix a real problem that programming really started to seem useful and fun. Brian talks about how he isn’t really the best programmer, but his strengths are helping other people to program. He has trained many people to program since then.

Learning with Context

He talks about in school how they throw JavaScript at you and teach you the higher concepts before understanding it. He tells about how doing something like teaching Git on the first day doesn’t make sense because the students don’t understand why they need it. He suggests that the thing that is missing from the curriculum is the real work connection. Majority of adults need to be able to connect what they are learning to something they have already learned. Context is important for learning.

How did you get into Ruby?

Brian talks about doing PHP for a while as well as ASP. He was working with a project as an Oracle DBA. They were moving from Java to an Oracle Database. But no one there knew what Java was and a person there named Bruce suggested that the work they were doing would be better written in Ruby. The team disagreed but afterward one day Brian was talking to Bruce about a side project he was working on and how he wasn’t accomplishing it the way he wanted to. Bruce asked him to get lunch with him. Brian then talks about how in life if someone very smart asks you to get lunch that you should drop everything and do it. In a single night he was able to accomplish everything he was trying to. He took his project to work the next day and they said they wouldn’t be able to use it on Windows. Brian started working on finding ways to deploy it, and that has been the starting point of Ruby for Brian. He went to Rails full time after that. Publishing an article on how to get it deployed. His work with Ruby led to him teaching and writing books. When he needs to make something heavily data driven he always reaches for Ruby. He isn’t interested in scalability because usually he is working on a small business process behind the firewall used by less than 100 people.

Framework Peer Pressure

Brian talks about the fear and pressure to use the latest and greatest frameworks in the development community. He talks about how the only people who know what framework a person uses is the developer and the peers. You don’t get paid to impress peers in the community. A developer gets paid to solve peoples problems. Charles and Brian add that using new frameworks are great and can teach you new ways to solve problems, but no matter how a person solves a problem, it should be celebrated. Learn new things but don’t make people feel bad for not doing things the same way you do them. Brian adds that another reason he likes Rails is that it has a lot of things that came from basecamp and it is a well developed and tested and the framework is strong. He talks about how sometimes frameworks come out and they weren’t well thought out. Rails is not an academic framework but it is easier to integrate or upgrade to by design.

What contributions have you made to the Ruby community?

Brian talks about getting the Rails deploy working for Windows is one of his proudest moments. Other than that his contribution has been mainly helping people find mentors at Railsmentors.org. On Railsmentors.org, most of the work is done by volunteers and help a lot of people. Charles adds that sometimes open source project contributions tend to get glorified but things like Railsmentors.org are really what make the community great.

What are you working on now?

Brian talks about how he is working on a book but he can’t tell much about it at the moment. He also works on the content team on Digital Ocean. He helps other community authors with their writing and to get it published and out. He also handles some system admin background to test that each article works and he finds it a good way to keep his skills tuned. He is also working on a project in Elixir for teachers to work in the classroom better. For a teacher teaching development they can use the program, CodeCaster, to display code to the screens and the students can do things like flag things they don’t understand or let the teacher know that it’s moving too fast. It allows the students send up code for the teacher to check as well as the teacher get a snapshot of what’s on the students screen to check on them.

Picks Brian

Exercises for Programmers
Tmux 2 Productive Mouse-Free Development

Charles

Coursera on AI
Artificial Intelligence in Python

Links

Twitter
bphogan.com

RR 316 Learning Rails 5 with Mark Locklear

On today’s episode, we have Learning Rails 5 with Mark Locklear. Mark works for Extension.org. The discussion ranges from the introduction of Learning Rails 5 to the strategies that most successful students have for learning Rails. Stay tuned!

[00:01:30] – Introduction to Mark Locklear

Mark Locklear works for Extension.org, a USDA-funded or government-funded organization. He serves the Cooperative Extension Service but a lot of people know about 4-H Youth Group. They got a handful of websites that they maintain that are mostly Ruby on Rails-based.

He has been with Extension.org for about 3 years. He is also a staff at a community college mostly doing Rails and IT things. He is also an adjunct instructor at the same community college. He was mostly doing quality assurance and testing work but moved into development work in the last 7-8 years.

Questions for Mark Locklear

[00:03:00] – You authored Learning Rails 5?

It was an actually an update on an existing book – Learning Rails 3. Mark is an adjunct instructor and used that book. He contacted the developers or the original authors in O’Reilly so he can update the book. He updated a lot of the syntax and rewrote a couple of chapters. He also wrote the authentication chapter from scratch.

[00:04:15] – What’s unique about your book?

For Mark, there are all kinds of learners out there. There’s nothing necessarily unique about this book. It approaches Rails from a standpoint of having really no development skill at all. The only assumption would be that reader knows some HTML and basic things like for loops and conditional statements.

[00:05:30] – Has Rails gotten more complicated?

That was one of the challenges with this book. The original version of the book didn’t have any API stuff, any Action Cables, or anything like that. But now, we’re looking on adding chapters on those things. Mark doesn’t think Rails is hard to learn now. It’s been pretty backward compatible over the years. It looks very much like it did 5 or 10 years ago.

Dave thinks Rails started to standardize a lot of things and with Convention over Configuration, a lot of it is taking care of it for you. The also added a lot of new features like Active Job (Rails 4), Action Cable (Rails 5), Webpack (Rails 5.1). He think that when someone gets accustomed to it, it’s almost second nature. Thanks to Convention over Configuration and the support for the community.

According to DHH, Rails is not for beginners. It is a toolkit for professional web developers to get stuff done. But Brian disagrees that it’s not for beginners. It’s not so much that it’s harder to learn but it’s just a little harder to get started with. There’s just lots of different ways you can do in a Rails application by using RSpec, Cucumber, etc.

[00:12:20] - What are the core fundamental things to know in order to write Rails apps?

Mark spends a week on testing in his class. He focuses more on the Model View Controller paradigm. He also used RSpec and the basics of CRUD. Those things are transferable across whatever framework that they choose to work in. He also want to hit testing, sessions in cookies and user authentication.

[00:18:30] - Is there an approach for people to enhance their experience as they learn Rails?

Jerome believes in the “just keep it simple” methodology. When it comes to Rails, just learn Rails. Just focus on CRUD apps. Focus on the entirety of the framework, and not only on Rails, focus more on Ruby.

Another suggestion from Brian is to start cracking open the Ruby source code, Rails source code and see how things work under the hood. Look at things and see if you can reproduce them or write your own implementations as you learn.

[00:24:30] – What are the strategies of your most successful students that you’ve had for learning Rails?

In Mark’s class, they have final projects with very strict requirements, basically going back and incorporating everything that they’ve learned. The app has to have a user authentication. It has to have sessions and cookies. And students who are most successful want to solve some problems and have the passion.

One of the things that Brian have always seen that separates people who are high performers from the rest is that they’re doing a lot of practice. Spend a lot of time practicing and building apps.

Dave encourages the listeners to work on some personal projects that they are passionate about. Deal with someone else and get some experience with some peer programming. Try to see what it’s like working with other developers on the same application, you’ll find that your codes much cleaner because you have to take into account multiple users working around the same code set.

Jerome suggests to find a mentor, someone who’s willing to spend time to help with your programs. The students who are talking to their mentors every week usually come to be the strongest. And mentoring is a rewarding two-way street.

[00:40:05] – Are there any other aspects of learning or teaching Rails that we should dive into?

Mark says you should be uncomfortable every once in a while in implementing new technology. It puts you in the same mindset as your students becomes sometimes it’s becoming incredible overwhelming. And when teaching, Brian does not start with complex examples.  He starts with simple ones.

A faculty mentor has to observe Brian in his teaching. The mentor will say, “Just a reminder. You are the guide on the side, not the sage of the stage. You’re not there to tell them everything. You’re not there to make everyone think that you’re the coolest person up there. It’s your job to guide someone to the solution.”

[00:49:25] – If I’m a Rails 3 developer, how do I learn Rails 5?           

Mark thinks that the approach is probably the same if you’re doing Rails 3 to Rails 4. The questions you will start asking yourself is, “Okay, what areas do you want to dig deeper? Do I have to use Active Job or something like that? What are my mailers? Are there additions to the framework?”

Whenever Rails releases a new version, Dave reads the blog which highlights the new features that were added in. Pinpoint those features, do a little bit of independent research and think how you could incorporate them into your application. Use them as guiding tools to upgrade your older Rails application to a more current version.

[00:52:15] – Two Writing Assignments for New Programmers

Mark wrote a Medium article entitled “Two Writing Assignments for New Programmers.” In his class, they have two writing assignments. One of it is on diversity and technology. They also use Moodle as the learning management system where they can post questions.

He got some push back from students but his explanation was that, part of being a developer is to be an effective communicator. Brian agreed and said, “Your job as a software developer is 20% coding, 80% dealing with people, their problems and their requests.” You have emails to read. You have emails to write. Brian always asks, “What are the most important skills you want our students to have?” The top 3 are always soft skills like communication, work ethics, etc.

Mark adds that if you can’t do writing, if you can’t show up to work on time and communicate with your colleagues, then, none of your technical skills matter. However, if you can’t past the technical hurdle, you’ll never get a chance to use your soft skills. Dave also adds that if he can’t get out of these people what they’re envisioning, then, they’re going nto develop the wrong things.

Picks

Dave Kimura

• Gruvbox

Brian Hogan

• Keys to Great Writing by Stephen Wilbers
• Rails

Jerome Hardaway

• Rails 5.1 Loves Javascript (Medium article)
• Hackerrank

Charles Max Wood

• Castle Clash
• railsmentors.org

Mark Locklear

• Grammarly
• History of Pi by Petr Beckmann
• Sierra Nevada’s West Coast Stout
• Github @marklocklear
• Site locklear.me

My Ruby Story 315 Jordan Hudgens

In this episode it’s another My Ruby Story and this week’s story is Jordan Hudgens’. Jordan is lead instructor of Bottega, a code school based in Lehi, Utah but also located in Phoenix and Salt Lake City. You’ll hear a bit about how Decamp.com came to be as well as what makes it stand out from the rest. You’ll also catch a couple tangents including one on artificial intelligence, augmented reality, an IoT. Don’t miss this one!

How did you get intro programming?

Jordan talks about how at the age of 12 his father had a business and with their budget couldn’t afford a web designer. His father offers Jordan to buy him a computer if he can build the website. He muddles his way through HTML documentation to create his first, and particularly ugly website 20 years ago. When he turned 16, he started working on better applications as well as learned PHP.

How did you go from PHP to Ruby?

As Jordan got further and further, he worked a lot in the energy sector, including Chevron and Oxy. This sort of work became dull and boring for him. He knew that there were other things out there that would be better. He started learning Ruby and fell in love with it. He mentions that working with Ruby helped him to love coming into work. Jordan now works almost exclusively in Ruby on Rails now.

What have you done in Ruby?

Jordan talks about switching all of his work over to Ruby, including doing work for Quip, the toothbrush service. He has also done work for EventBrite on one of their Micro Services. He soon after quit his work to start devcamp.com and launch his own learning platform. He says that he learns best by teaching so he started to create courses, usually for himself. He self-published on platforms like Udemy, but was also hired to create courses for FlatIron School in New York. His time was spent less in development and more in creating courses.

What makes the DevCamp.com different? What was your inspiration?

As a developer and having his own consulting shop, he recognized that camps weren’t teaching certain things like algorithms and even soft skills like project management and estimation. He also wanted to include other things like machine learning. Jordan felt strong on what he felt a true job centric curriculum should be focused on. Uniquely, Jordan has created a strong network to hiring partners. Instead of just building a course, they build outlines for a certain topic and then has the hiring partners and network to help create a profile for the best candidate for hire. Then creating the workshop around those requests. A major element that makes Jordan’s Devcamp.com stand out is that they are one of the only accredited bootcamps out there. Devcamp also uniquely has a 2 year pathway mapped out similar to a university computer science curriculum. Universities have partnered with devcamp.com because the curriculum lose a little bit faster than the traditional taught curriculum. Students are getting hired a bit faster because they are learning more relevant information. Jordan states that the student’s success is also Devcamp.com’s success.

What are the skills people need to actually get a job?

What makes a great developer is problem solving. Problem solving is the most important. If a person can dissect a challenge and come up with a plan, it’s very valuable. There is a problem solving course that presents a number of challenges where students learn to problem solve, not even using code. Taking a practical approach to give a sense a real world relevance and a mental framework for problem solving.

Do you feel like your main contribution was teaching?

Jordan mentions that he tries to contribute to open source and that he has made a few Ruby Gems but his time is limited. He discovered that even when he was making good money developing, he didn’t feel like he was making a huge difference in the world. He talks about watching students who came from working minimum wage jobs leave the camp they started working very hard and making 50 to 60 grand a year. The camp changed their lives. Charles talks about how he relates with the podcast. People have come to him with similar stories of having enough confidence to change their careers after listening to the podcasts.

What are you working on now? Anything new?

Jordan talks about how most of his time is developing new ‘Products’ for Devcamp. Each day he tries to add a few new features. One of the big plans is to start including machine learning into the curriculum. He talks about how when he adds features, he tries to use those features to teach and to create a relevant real world example. He finds that most students don’t like abstract thought patterns.

Are you doing that with Ruby?

Jordan lets us know that yes some of the machine learning stuff he is working on is with Ruby. Interestingly enough, he spent time at the Rails Conf and went to every machine learning talk there. Every single machine learning talk was on Python. He mentions that “H.H’s” (David Heinemeier Hansson) keynote talk was on using the right tools. It’s hard to compete with the large number of libraries that Python has on machine learning.

Artificial Intelligence, Augmented Reality, and Iot

Charles suggests that artificial intelligence, augmented reality, and Iot are really where technology is heading. Jordan and Charles talk about how they all three interplay together to enhance our lives. adjunctSensors from an Iot device uses machine learning and artificial intelligence to make decisions that then tie into how we experience reality. Charles mentions that he often tries to convince people that their phones are already supplementing our lives in a way that makes it augmented reality. Machine learning seems to be the glue that holds it all together.

Picks Jordan

Devcamp
Bottega
Tim and Ruby Topaz

Charles

Ruby Dev Summit
Wordpress theme - Summit
Ruby Rogues Parley
Meetup.com

Links

Bottega
Devcamp.com
Twitter
GitHub
Crondose blog

Offshoring and Latin American Developers - David Hemmat

For this episode of Ruby Rogues we have Jason Sweat and Brian Hogan for our panel along with Charles Max Wood and a special guest, David Hemmat from BlueCoding.com. David and the Blue Coding team work to connect developer talent to businesses in need through a thorough process of vetting as well as a database collection of potential developers. Check out this episode to learn more!

How did you get started? 1:34

David talks about going to school in the Dominican Republic worked locally, but later found work with US companies. He also set up a friend with a US job and they realized that there may be a demand as someone to bridge the gap. Developers did not have the access or a way to reach opportunities aboard so he started BlueCoding.com.

About Blue Coding 2:32

BlueCoding.com has clients in the US and Canada. They focus on Latin America due to having close timezones in relation to the majority of companies that would be looking for developers. Also, Blue Coding helps in regard to bridging the cultural gap. Latin American work culture can be different that US or Canadian culture. David talks about how it’s much of a communication difference. Developers sometimes will agree to jobs they are unable to do and are timid to communicate and often just disappear. Despite this, many Latin American companies spawned from United States companies and will tend to have a similar working environment and culture as US companies.

The General Experience With Offshore Hiring 4:17

David and the panel chat about their offshore hiring experiences. David expresses that there is sometimes an issue of many developers taking on work, and then seemingly disappearing. Often times coming back with excuses or in some cases actually over committing to work and just failing to communicate properly from the start. In some cases, like with countries like Venezuela, has a less reliable environment for the developers with things like power outages.

“Not All Good Developers Are Good Freelancers.” 6:18

Freelancers tend to need a different skillset. Extra communication and need tools in place like time tracking and daily reports , etc. Companies that hire freelancers or offshore hiring in general need to have tools setup as well. David expresses that the best developers often are the ones that already have full time jobs. Blue Coding tries to help those developers find a better opportunity and has structured systems to create a workflow that works for both parties. David talks about having those tools in place for the developer including the time tracking and daily reports.

The Companies Tools. 8:33

Blue Coding will also check with the client companies to make sure they have tools as well to help both parties have a smooth workflow. Project management software for the developer to see what they should work on next.

Rates 9:04

Rates vary between $30 and $45 an hour. David tries to stay away from junior developers, looking for developers with 3–4 years working experience. Some companies pay $30 to $60. Latin American countries generally see a starting rate of $30 an hour. Asian countries can start as low as $10 an hour, but in rare cases. Some developers on the opposite side of things charge $100 an hour.

Getting Offshore Developers 10:47

Most people start with upwork.com or Freelancer.com or something like that. Lower overhead but very limited vetting. Buyout fees are very high as well on these sites. There are companies similar to Blue Coding that are staffing companies that exist. Also, direct networking. Networking directly is extremely efficient. If you have a bad work history, networking also comes into play. David talks about their biggest source for developers are other developers, reaching out to find good hires by networking through the community.

Dealing with ‘Boom and Bust.’ 14:19

Freelancers tend to run into boom and bust cycles, loads of work followed by slow spells. David tries to avoid this by hiring carefully and picking clients carefully. Looking for long term projects, either be a continuous flow of projects or one large projects. With this focus on long term relationship building, BlueCoding is able to have much lower rates. Other companies usually don’t have safety from downtime, offering internal work to make up for it.

Finding Companies that Hire Offshore 16:08

Most countries have job boards to help. Also, technology specific job boards. But it’s hard to compete there. US companies won’t hire offshore developers for the same rates and the same skills. You have to be really good. David pushes developers to have plenty of experience.

How to Get Noticed? 17:46

Companies can be prejudice, but isn’t seen too often. Becoming a top level talent is key. Being average is harder. As an average or novice in an area with no community, finding online communities, Facebook groups, LinkedIn communities, working on open source projects, and going to events can help.

Working remotely and being good at it [22:02]
It’s a two part effort. Companies can have tools to make things easier, but as a developer, you can request them. Communicate all online. All of the office talk should be online via Slack or some other documented system. Code reviews and Peer programming helps remote developers feel like a part of the team.

Onshoring vs Offshoring 24:28

Some companies are hiring remote developers from the US. Why would someone want to hire from outside the country? Ultimately it comes down to finding a developer that fits in with what a company needs as well as matches the budget. Cost of living can change the rates for developers as well as where the company is located. David expresses that he wants to find really good developers, even if it means reaching out to Brazil or other parts of Latin America.

Medical, Taxes, and Benefits 24:43

Each country has different laws. For example Dominican Republic has a law that states if you contract someone for over 3 months, they are considered employees and require benefits. Some countries allow Freelancers to work long term. Health care varies between companies.

The Finical and Risks. 32:14

Freelancers and hourly workers tend to have less working time, spending some time each day to chase down work as well as managing time. Developers in general should notice that projects in general can have budget cuts and even end prematurely. In general a developer working as an employee will need to account for the benefits and extras thrown in when considering their rates.

The Companies 34:02

What kind of companies are looking for this as a solution to their staffing problem? Most companies are smaller companies, 1 to 20 employees with a lot of long term development work. Generally three sectors, non tech companies that need tech work, digital agencies, and tech startups or established companies that already have a software product that needs to be maintained.

How to find the Companies? 36:30

It’s a work in progress. References are vital, David talks about how vetting for developers ends with a very happy client that gives references. Also they spend a lot of time networking, conferences, meeting people online as well as cold calling. David mentions that it’s hard to express the quality of their service through email.

Getting Started with Blue Coding? 37:22 For Developers

Go to BlueCoding.com and find the link that says “join the team if you’re a developer” and you can connect that way. Just reach out to them and they will set up a conversation with you and see if there is a good fit. Then once a project comes in they will set you up with the vetting process.

For Companies

BlueCoding will want to set up a call with you. Reach out to them and setup a call. They will work through if you need a developer and what that developer looks like in regard to technical skills, personal skills, and general ability.

Then the developers and clients have a meeting to make sure everyone is comfortable. Being comfortable is the most important part for this connection to end in a long term relationship.

Picks Jason

Samsungnite Columbian Leather Flat Over The Top Laptop Bag

Brian

New MacBook with Touch bar

Charles

My Ruby Story Podcasts
Online Summit Format
Ruby Dev Summit
Ruby Rogues Parlay on Slack

David

Micro Conf.
Macbook Air
One Minute Manager

Links to Keep up with David

His Medium
BlueCoding.com
Email him

My Ruby Story with Charles Max Wood
This week’s episode is a bit different. Charles Max Wood interviews… Charles Max Wood! Hear a bit about how Charles’ grandfather inspired him towards his career in programing, how handling technical support for Mozy somehow led him to writing Ruby code, and hear a bit about what he is working on now! Stay tuned.

How did you get into Programming?
Charles talks about remembering some of his first programming exposure as far back as second grade. He talks about programming the iconic turtle to move around on the screen and draw shapes. Later on he had more experience in a particular Math class in high school, this time Pascal, then of course the TI-85.

Inspired by his Grandfather
Charles gives a bit of a background story on his inspiration for taking electronics classes in school, his Grandfather. His Grandfather was an inventor that created various inventions, including tools used in the manufacturing of rocket boosters for the NASA Space Shuttle. Charles became very interested in electronics and took his first electronic class.

Electrical engineering in College
Charles then attended Brigam Young University majoring in Electrical Engineering, giving him even further chances to experience programming. To Charles, programming seemed fun but didn’t feel serious enough to hold weight as his career. His interest grew in computers. He eventually switches to Computer Engineering and graduates, also picking up a job in the office of information technology at BYU.

Programming gets more serious
Charles talks about how programming in college tended to lean towards games and fun projects, and it wasn’t until after college that the projects that he got involved with felt as if the work he was doing meant something. From building a system to help college students find apartments that fit their needs, to Bash scripts that made some of the IT updates at BYU faster and safer.

His first job with Ruby on Rails
Charles then lands a job with Mozy, the popular online backup service. Mozy’s systems were all running with Ruby on Rails and Charles worked as Technical Support. Mozy gets publicity in The Wall Street Journal, increasing the Technical Support workload. Charles then writes a Ruby on Rails system that created a smoother flow when cycling through emails. He soon added extra features like canned responses and a way to measure how often canned responses were sent as a way to highlight any particular issues Mozy was having.

Shifting into Podcasting
Charles talks about switching from a Management position to a developer track and working with a man name Don, who had an original iPod and listened to podcasts. Introducing him to Rails Envy, a podcast by Jason Seifer and Gregg Pollack. After emailing Gregg, to Charles’ surprise he responds and encourages him to start his own podcast. Charles talks about how he feels his main contribution to the Ruby community is his podcast. Since then he has had a chance to interview some really influential people, including David Heinemeier Hansson, the creator of Ruby on Rails. Outside of the podcast, Charles adds that he has also taken over Teach Me To Code and has contributed a few open source libraries, one connecting to project HoneyPot, as well as contributing indirectly through his other podcast work including JavaScript Jabber, and Adventures in Angular.

What are you working on now?
Charles talks about hoping to get back into writing open source code and even starting a project. Charles spends most of his time doing ‘businessy’ stuff for the podcast as well as the conferences, currently working on putting together a Ruby Dev Summit. Charles talks about a few new podcast shows he is working on, including bringing some requested content like web application security, React, and Elixir. Charles talks a bit about other things he is involved in at home and creating systems to help him manage his busy workload.

Picks
Electro-Voice RE20 Microphone
Behringer Xenyx 802
Roland EDIROL R-09
ZOOM H6
Audio Technica 2100
GetACoderJob.com

Charles’ Links
Devchat.tv
Charles’ Twitter
Devchat.tv’s Twitter
Charles GitHub
Chuck@devchat.tv

RR 314 DynamoDB on Rails with Chandan Jhunjhunwal

Today's Ruby Rogues podcast features DynamoDB on Rails with Chandan Jhunjhunwal. DynamoDB is a NoSQL database that helps your team solve managing infrastructure issues like setup, costing and maintenance. Take some time to listen and know more about DynamoDB!

[00:02:18] – Introduction to Chandan Jhunjhunwal

Chanchan Jhunjhunwal is an owner of Faodail Technology, which is currently helping many startups for their web and mobile applications. They started from IBM, designing and building scalable mobile and web applications. He mainly worked on C++ and DB2 and later on, worked primarily on Ruby on Rails.

Questions for Chandan

[00:04:05] – Introduction to DynamoDB on Rails

I would say that majority of developers work in PostgreSQL, MySQL or other relational database. On the other hand, Ruby on Rails is picked up by many startup or founder for actually implementing their ideas and bringing them to scalable products. I would say that more than 80% of developers are mostly working on RDBMS databases. For the remaining 20%, their applications need to capture large amounts of data so they go with NoSQL.

In NoSQL, there are plenty of options like MongoDB, Cassandra, or DynamoDB. When using AWS, there’s no provided MongoDB. With Cassandra, it requires a lot of infrastructure setup and costing, and you’ll have to have a team which is kind of maintaining it on a day to day basis. So DynamoDB takes all those pain out of your team and you no longer have to focus on managing the infrastructure.

[00:07:35] – Is it a good idea to start with a regular SQL database and then, switch to NoSQL database or is it better to start with NoSQL database from day one?

It depends on a couple of factors. For many of the applications, they start with RDBMS because they just want to get some access, and probably switch to something like NoSQL. First, you have to watch the incoming data and their capacity. Second is familiarity because most of the developers are more familiar with RDBMS and SQL queries.

For example, you have a feed application, or a messaging application, where you know that there will be a lot of chat happening and you’d expect that you’re going to take a huge number of users. You can accommodate that in RDBMS but I would probably not recommend that.

[00:09:30] Can I use DynamoDB as a caching mechanism or cache store?

I would not say replacement, exactly. On those segments where I could see that there’s a lot of activity happening, I plugged in DynamoDB. The remaining part of the application was handled by RDBMS. In many applications, what I’ve seen is that they have used a combination of them.

[00:13:05] How do you decide if you actually want to use DynamoDB for all the data in your system?

The place where we say that this application is going to be picked from day one is where the number of data which will be coming will increase. It also depends on the development team that you have if they’re familiar with DynamoDB, or any other NoSQL databases.

[00:14:50] Is DynamoDB has document store or do you have of columns?

You can say key value pairs or document stores. The terminologies are just different and the way you design the database. In DynamoDB, you have something like hash key and range key.

[00:22:10] – Why don’t we store images in the database?

I would say that there are better places to store the, which is faster and cheaper. There are better storage like CDN or S3.

Another good reason is that if you want to fetch a proper size of image based on the user devices screen, resizing and all of the stuff inside the database could be cumbersome. You’ll repeat adding different columns where we’ll be storing those different sizes of images.

[00:24:40] – Is there a potentially good reason for NoSQL database as your default go-to data store?

If you have some data, which is complete unstructured, if you try to store back in RDBMS, it will be a pain. If we talk about the kind of media which gets generated in our day to day life, if you try to model them in a relational database, it will be pretty painful and eventually, there will be a time when you don’t know how to create correlations.

[00:28:30] – Horizontally scalable versus vertically scalable

In vertically scalable, when someone posts, we keep adding that at the same table. As we add data to the table, the database size increases (number of rows increases). But in horizontally scalable, we keep different boxes connected via Hadoop or Elastic MapReduce which will process the added data.

[00:30:20] – What does it take to hook up a DynamoDB instance to a Rails app?

We could integrate DynamoDB by using the SDK provided by AWS. I provided steps which I’ve outlined in the blog - how to create different kinds of tables, how to create those indexes, how to create the throughput, etc. We could configure AWS SDK, add the required credential, then we could create different kinds of tables.

[00:33:00] – In terms of scaling, what is the limit for something like PostgreSQL or MySQL, versus DynamoDB?

There’s no scalability limit in DynamoDB, or any other NoSQL solutions.

Picks

David Kimura            

• CorgUI

Jason Swett     

• Database Design for Mere Mortals

Charles Maxwood

• VMWare Workstation
• GoCD
• Ruby Rogues Parley
• Ruby Dev Summit

Chandan Jhunjhunwal     

• Twitter @ChandanJ
• chandan@faodailtechnology.com

Today's episode features the Ruby Story of Jamis Buck. James guested on episode 268, where he talked about Mazes for Programmers. For 9 years, he worked at 37Signals as Software Developer. How did he get into programming, and what is he currently up to? Tune in!

How to Handle WTFs

On today’s episode of Ruby Rogues we are chatting about WTFs. On our panel we’ve got Dave Carmona, Brian Hogan and I’m Charles Max Wood. We talk a bit about some of the recent WTFs we’ve encountered and some of our tricks for handling it, including talking to a Rubber Duck. It’s a fun episode so check it out!

WTF’s in Two Flavors

Charles starts out the episode inquiring to the panel about two different kinds of WTFs. The whats and the whys. WTFs that happen and developers don’t understand what the WTF is, and then on the other hand WTFs that happen and the developer doesn’t know why it’s happening.

Unreadable Perl and the Rubber Duck

David talks a bit about how hard it is sometimes to read and understand what is happening with Perl code, even if you wrote it yourself. Sometimes debugging Perl codes many years later, running into syntax errors end up being a ‘Why’ WTF. He introduces a method to use for ‘Why’ WTFs that he calls the ‘Rubber Ducky Debugging’ method. The ‘Rubber Ducky Debugging Method’ is when you place a rubber duck on your desk, and when you encounter a WTF you can simply talk through the issue to the duck to help you think through your issue. Brian and Charles add that this method works fine with real people as well and have done it many times with their wives, even for issues that don’t involve code.

Blaming it on Past Brian

Brain mentions that sometimes when working with someone else’s code, it’s easy to blame the previous developer. Unfortunately in his case, Brian finds that “Past Brian” has often been the culprit.

Dave and Code he Doesn’t Understand

When encountering classes that are really big with many different methods, find the entry point. If it doesn’t have a traditional initializer or call method for the entry point, you can look around other relevant parts of the code to try and figure it out. Sometimes if it’s obfuscated, you can go through variables and rename them to more relevant names to identify what they are doing to help understand the method at hand.

Puts Debugging

Aaron Patterson had written an article on his blog about ‘Puts debugging’ that turned Dave onto the the untraditional debugging method. Dave will sometimes write a separate debugger class to separate puts into a different log to keep it organized.

Brian’s Version of Puts Debugging

Brian mentions that when working on a rails application he will sometimes raise the object he wants to inspect. Errors in Ruby are often something you wouldn’t expect and being able to quickly inspect the object using raise .Using raises the whole stack including the object, session, and cookies , etc.

Dave’s Ruby Lifesavers

Dave also adds that adding the gems to your development better_errors, and then en binding_of_caller are lifesavers. It allows for a more interruptive session with raised errors. Also, in Rails 4 the console feature was added, allowing you to tweak things and play around to debug. Also, Pry is really useful for loop through and investigate. Dave also notes that Pry, while being a great tool, can sometimes be a bit annoying if you have a large number of loops.

Crazy Bug Story - Brian

Brian talks about how in Elixir the declaring of methods is very similar to Ruby but at the end of Elixir method calls you add keyword do. If you do this in Ruby, the interpreter’s error message is unusual and doesn’t give any information that helps you find the issue, making it very hard to find the issue. This could be very time consuming for the debugger. He adds that having a second pair of eyes helps with issues like these.

Crazy Bug Story - David

David talks about working on a personal project late into the night. Using Rails 5.1.1, he thought that maybe his issue with the enumerators. He considered that maybe the issue was with Rails 5.1.1 being that is newer. To test to find out if he caused the error, he recreated a simple bit of code that uses enumerators and saw that it worked, then created the same project in 5.1.1 and it also worked, concluding that he created the issue. Later he found he declared the datatype for the enumerator as a string instead of an int. Brian added that creating a fresh application to test for errors is a great way to start debugging, in comparison to immediately to asking others what the problem might be. This method of checking can have a quick pay off if the code is simple. Also, creating new applications to test gives a great foundation of knowing that the problem is in your own code.

Crazy Bug Story - Charles

Charles’ bug was something he encountered in his podcast feed application he created in Rails 4. Charles didn’t read the error message very well so he tried it debugging it with Puts Debugging. It’s turned out that he was using a strftime method that he had accidentally formatted the string wrong, using -’s instead of /’s.

Characterizing with a Test

In issues like Charles’ you can take input that’s going into a method and then setup an integration test. Tests like this can be made fairly quickly. By copying and pasting the input parameters into a test like a Capybara test, then you can get a better idea of where the issue actually is.

Creating the Error to Fix the Error

Brain mentions that sometimes when he has a specific error, he will try to write a new set of code that reproduces the issue. Then from there he will try to ‘break’ the broken code in efforts to find a debugging solution in the original code.

Making your Production Environment The Same as Your Development Environment

If you’re using something like caching in your production environment, make sure it is set up in your developmental environment. Debugging caching issues can be some of the most complicated bugs to fix. If you set up your environment to be the same it helps. If you need to start the caching over during development or tests, it’s as simple as a CLI command. When you’re doing feature tests, if you do it with caching enabled, you can use timecop. Timecop allows you to essentially time travel to test timing issues without having to wait.

Favorite Development Tools

Some of the panelist’s favorite tools are Pry, binding_of_caller, better_errors, Konami, and Sinatra. Google Chrome’s RailsPanel extension Works like MiniProfiler, but digs in further. By adding this gem to your development environment and running it on Chrome, it shows you all the requests that come through, the controller in action, and lists out all the parameters, as well as active record calls and errors.

Favorite Production Tools

Brian suggests using any tools available to capture exceptions and error messages. Capturing these issues before the user contacts you makes recreating the issue and debugging it a lot easier. Dave mentions using New Relic to capture performance of application as well as error notification. With New Relic you can adjust the notification threshold and give it actions like sending it to a Slack channel. Then use something like Sumo Logic to concatenate and combine the logs if it’s coming from various servers.

Shipping Logs Off

FluentD can be used to ship off logs to analyze. In some cases management won’t be okay with shipping things off. Doing things internally can sometimes be too much and using a third party aggregation tools can be helpful.

Some Tools Can Be Heavy

Sumo Logic applet is Java based and takes up quite a bit of space. Jenkins is also a Java setup and takes many parameters to get running. In some cases with smaller applications, applets like Sumo Logic can take up more space than the application. Trying to parse multiple servers can be daunting and will definitely need a centralized logging option.

Other Logging Tools

Elastic.co and Logstash are other logging tools. They have integrations with tools like Docker and Kibana. If you can roll your own logging tools then great. But it’s usually time consuming and takes resources.

Getting Information from People and Assume It’s Wrong

Charles mentions that in some cases, especially in cases where something you’re using is dated, resources can be limited to get information on a bug you’re having. Brian suggests that when this happens, getting information out of people is a good place to start. Also, when getting information from people, assume that it’s wrong. People tend to have a pretty poor recollection of what happened. You can sometimes take what they say and compare it to the logs to create tests and logically work out how something has happened. Users will sometimes leave out things like accidentally leaving a field blank, or hitting backspace, or something simple. Extracting information from the users to get relevant information is a skill. Sometimes the best way to get information from a user is to just watch them use the application. Sometimes they will use the application in ways unexpected. Approaching the problem with “Let’s fix this together” helps with getting the client to help.

Getting Access with Production Data

David mentions that If there is an issue with the production side of things, pulling data down into your own database and your own separate testing environment can keep it safe while debugging. If you’re able to recreate the issue than most likely it’s an application issue, otherwise it’s something to do with the environment like caching.

Safely Percautions of Having Client Data on Your Computer

If you’re pulling data down, you should absolutely have your devices encrypted. There is no reason not to. Also when pulling data down, you can create a mirror of the data dump. There are systems that dump data that will also obfuscates or remove particular information including personal information like emails.

Troubleshooting ActionCable: Step 1 - Cry in a Corner

David tells how he was troubleshooting an Actioncable issue and his first step was to cry in a corner for 5 minutes. Afterwards he used Chrome Dev tools to trace back the code’s method where it was getting declared. Sometimes if an application is complicated it can be running many moving parts and be difficult. When debugging something complicated start at the browser level. Check for connection then try pushing a message in the console. If you get it then you’re connecting but not broadcasting. If you have a complicated subscription model for authorizing a channel, it can be even harder, again start with checking to see if it’s connecting.

tail -f | grep ‘exception’

Charles remembers a simple way to watch for issues while debugging. A simple use of tail -f | grep ‘exception’ tails the logs and shows only the exceptions. You can use this along with Put debugging by putting the word in all your puts.

Picks Brian

Learningmusic.abelton.com

David

RailsPanel
His new 5 foot long 12 plug power strip

Charles

Microsoft Build
.Net Rocks Podcast
Ketogenic Diet & Livin’ La Vita Low Carb
Rubydevsummit.com

Tune in as Charles Max Wood interviews Fabio Akita! Fabio has been working on Ruby for more than 10 years. He also blogs about it, and participates in Ruby Conf and in the programming community in Brazil. He appeared on episode 285, where talked about the conference and the community. Learn more about his journey and contributions in programming.