CSC 321.01, Class 11: Visits from alumni mentors

Overview

• Preliminaries
  • Notes and news
  • Upcoming work
  • Extra credit
  • Questions
• Your questions
• Their answers

Preliminaries

News and notes

• I brought food.
• Alumni mentors visit Wednesday. Please try to clear lunch time, 4pm for their talk, (and 1pm, if possible).
• We’ll talk about code smells and legacy code in a few weeks. I may bring the code I had to work with this weekend. I spent over four hours tracking down a bug (in part because it was so badly designed).
• I think I’ve fixed the schedule.
  • Links are to eboards rather than outlines. (Future links don’t work.)
  • Changed due dates of assignments.
• Mentor sessions Tuesday and Thursday.

Upcoming work

• Hartl 5 due Tuesday at 10:30pm.
  • Extend by two days. Please break up your work.
  • I still need to find a three-hour block to write that assignment.
  • Python people should find an alternative.
  • You will have time to work on it on Monday.
• Hartl 6 due Next Tuesday at 10:30pm.
  • Extended by a few days. Please break up your work.

Good things to do (Academic/Artistic)

• Two cool shows in the Faulconer.
• Islam week events this week.
• Megan Goering design talk on Tuesday at 7pm.
• Wednesday visitors.
• Deej the movie this Thursday at 7pm in Harris.

Good things to do (Other)

Questions

Meet our mentors

WB - Works as “architect” of sorts, looking at big picture issues. Used to do more direct code development.

TK - GitHub. Does community services stuff, including apps for helping support community policing.

CK - Consulting firm. A bit of everything. Rails, iOS.

AL - Occam Health. Tech products for doctors offices. Team lead for microservices.

Your questions

Why Rails?

Everything else sucks more. The object-relational mapping is a really important part of Web development. That’s most of what you’re doing in the development of Web apps. (ORM) Node’s is buggy and not good.

Rails is opinionated. Rails is a really nice way to do a lot of problem. Abstracts away a lot of concepts.

Rails has a lot of conventions. You know where things go. The community has a rough model. Helps you know where to look. You’re speaking the same dialect as everyone else. (In this class, that’s less true, since you are less familiar with the model and the people who wrote your code are less familiar.) I can jump in right away.

But you can also get stuck in projects where people haven’t drunk the kool aid. In cases like that, it doesn’t update. “Just trust Rails”. Don’t do special things.

But sometimes the conventions don’t mesh with the kind of work you are doing (or your own strong opinions). Historically Rails is focused on “here’s a Web page for you to interact with” rather than “heres a JSON blog for you to use”.

You’re programming in Rails not in Ruby. There are many things that you rely upon that you don’t necessarily want to import into your project. Also views of how you develop stuff. Rails “monkey patches” existing classes, adding features to those classes. Load order affects this.

Ruby and Rails are a well-defined set of solutions to a particular set of problems.

“I have a database. I want to show things from that database.”
But not “I want to deal with threaded asynchronous stuff.”

Good for 90% of stuff.

Are you worried that you don’t know how things are working?

That’s the best part. It’s like a car. Do you really care how the parts of the car are working?

Helps take away the distractions. How are you interacting with the database? How are you loading Javascript? Etc. Etc. You know all the answers (at least where you normally look).

What’s something you wish you’d known as you entered the job market?

There’s always an opportunity to negotiate your salary. Ask for more.

It’s okay that you don’t have it all figured out. You’ll be better at some things and worse at others.

Have the fundamentals. You can develop the rest. Our field keeps changing.

Make sure that the leadership of the company is a good fit. Many jobs are simialr day to day. Things are shaped by the people with whom you work.

We are an industry in which six months at a job is not considered a black mark on your résumé.

What do you see in more successful groups?

Don’t be afraid to ask questions. They are remote. It’s hard for them to know that you need help.

Some groups work together all the time. Some split up into smaller groups. Both approaches can work and not work.

Pay attention to what is and is not working and adjust as necessary.

Communicate well in your groups. Keep folks informed.

Don’t have one person try to do all the things.

Make sure that everyone contributes. Self gov the group.

Is Rails conducive to splitting projects?

Yes, you can break things into functional pieces.

Robust testing tools help you with doing test-drive design.

Rails shops tend to be strong advocates of pair programming.

Try to keep MVC for one model together.

How did you develop this knowledge?

The Pragmatic Programmers book. [x2]

Things are better now. The Rails guides are pretty good.

Learn from looking at existing projects.

Having a need and then trying to solve it.

Rails weidnesses?

Unexpected blowup of code. Hard to identify because stuff is hidden and you usuall test small stuff.

One example is to hit the database multiple times.