Paulette Luftig

Destined Ruby and Rails Developer Extraordinaire

1 note

The Time is Now!

I finished up at DBC and feel intimidated, excited, alive as I step into the next phase of my career change, looking for work. Now that I’ve more time I hope to return to my blog. I have more to say and feel more committed than ever to make waves in this big world. And now I have a ton of new skills to work with! My gratitude in this moment is overwhelmingly sweet. 

2 notes

Dev Bootcamp - Day 8

Well, originally I was hoping to write before the end of every day. Unfortunately, I haven’t been able to keep up with that pace. The days are super long, and my nights aren’t as restful as I had hoped. The crazy thing about programming is I end up going to bed still trying to work out code problems in my head. It’s tough to shut it down and relax into sleep. The funny thing is I would stay up and keep working if I could; I want to know how to do this that much! 

I’ve learned a ton the last few days, even if I still feel like I’m at the bottom of the barrel as far as beginner learners go. On top of managing the challenge of not understanding, I am often needing to mitigate anxious feelings around my capacity to learn in such an intense environment. Some things, are nevertheless, sinking in.

Object oriented programming - without looking anything up, I can say a few things about what I know. First of all, it’s important to try and break class methods up in a way that ensures they don’t depend on another class. They will of course need to interact but it’s best to avoid dependency whenever possible. Also, classes can only inherit from one other class. Children inherit all the methods from the parent class but if necessary a child class can override a method from the parent. The cool thing though is that if I wanted to override a method, a parent class in a subclass method, I don’t have to abandon the entire method. By calling super in the child method I’m using to override the parent class method, I can use some but not all of the parent’s method.

The past two days I’ve also come to understand that I am struggling with how to call classes and class methods. I need to study up on this. While I feel confident about initializing a new object, working with that object, that is, calling methods on that object, still confuses me at times. When there are multiple objects in play it’s tough to hold all the moving parts. (I trust that things are sinking in though.) Something else key that I am grappling with is using attr_accessor, attr_reader or attr_writer, especially in relation to Separation of Concerns and the Law of Demeter. While I understand these concepts, putting them into action is another feat! I am just at the edge of a whole ton of ability dropping into me. I know it!

Yesterday we learned to use ARGV to run our methods/programs through the command line. Today we learned how to parse files using a ruby gem and we started working with website HTML and CSS data. I found conceptualizing what it was we were doing a lot easier, even if I still feel behind with my ability to write functional methods. I think what’s important for me to go to bed remembering tonight is that today I was thrown into grappling with a ton things I had never seen before and I survived. By the end of the day, what I was seeing was becoming more familiar. 

I feel grateful for the opportunity to grapple with my mind and my emotions at Dev Bootcamp. I feel alive!


1 note

Dev Bootcamp - Day 4

I wasn’t able to sleep well last night so today was particularly difficult because I wasn’t feeling well. I hit a wall when we started working on a program that involved completing a game. We were thrown into object oriented programming and for the hours I spent on that particular challenge I felt miserable. But after that something happened, meaning I got over the wall, found my strength and my positivity. I am too tired to blog about what I learned, even though I know it’s important to journal.

0 notes

Dev Bootcamp - Day 3

Well, it’s just getting harder. Tonight I left at 11pm and still have one and a half core challenges to complete. That’s what I’ll be woking on early tomorrow morning. I learned a lot today, although my learning was a mixture of code learning, social learning and learning about myself.

First I’ll share that I had a tough time pair programming. I paired with someone who really wants to work things out on his own, which is great for him but I found myself needing help a lot of the time and I didn’t ask for it soon enough. He also worked out the problems in his head and without engaging me, which was tough. When I had an idea, it wasn’t heard or asked for. I found myself losing interest in the process (at least with him). I learned by seeing his pseudocode and the finished product but didn’t get to practice thinking through a problem much myself. 

On the other hand, socially, I learned that everyone is really there to help one another. I suppose at times I doubt that and still smell competition in the room, but today I really felt the care and support of all the other Boots, not just from my cohort, but from everyone at the school. Teachers, too.

We had a lecture on engineering empathy today and we were informed that at the end of 3 weeks anyone that can’t keep up and really learn the material will be asked to leave. While I consider myself capable of holding a ton of difficult emotions, the thought of not succeeding at this threw me off most of the afternoon. When I got lost on a problem, I wasn’t able to think anything other than I am incapable. It’s a terrible loop to land in because the negative thought just feeds more negative thoughts until my brain is as worthless as an infinite loop.

So… I asked one of the teachers for help. Here are a few things he suggested. I should approach code challenges like I’m doing walking meditation. Slowly! Break the program down into the smallest pieces I can. He also suggested I use code I am comfortable with and rewrite it trying to do this same thing. This will help me get comfortable baby stepping toward the code I need to write. 

He also pointed out a few places he thought I might be unclear about. for example, using if / else statements. I actually feel pretty clear about this. Else is used for all other possibilities other than the initial if. Elsif is a more specific condition. Need to keep this in mind from now on. My teacher also encouraged me to google more. I find googling tough in pair programming situations but that’s really how I managed to do so well in the prep work. Google is my friend and I almost left her behind! The last thing I remember, although I think he said a couple other things, is to try things out on the computer more using irb or even just running the code in terminal. I will.

There are a ton of code specifics I could say I learned today. For example, break is a special word that can only be used in loops. Another, a proc is just a method saved in a variable. Pretty cool. 

I got scared today but I just feel more committed to getting over that and succeeding. Yes, it’s hard and that’s why I love it. 

0 notes

Dev Bootcamp Day 2 - rand

The other important thing I went over today was working with the rand method. Rand can be confusing particularly when it’s being used with an array, because in this case rand is choosing from the index places and not the elements. So, let’s say I have a rand(10)… this will give me back random numbers from 0-9 but it won’t result in 10 because 0-9 inclusive is 10 numbers. If I wanted to also get 10 I have to add one, but here is the trick: the addition of 1 has to happen out side the brackets: rand(10)+1. Now it’s safe to say I will get a random number between 1 and 10. I could also do this by setting a range: rand(1..10). One last thing. Rand uses round brackets and I tend to forget that. Also, when applying to something like an array, here’s how it could be written: array[rand(10)]… Square brackets are used here in the same way you would use them to get at array index places. Oh and one more thing, rand(1) returns floating point numbers between 0 and 1. Pretty cool.

0 notes

Dev Bootcamp - Day 2

Wow. I thought I was prepared when I walked into DB yesterday. Although I did my prep questions a number of times over, a strong capacity to really think things through and see all the moving parts is going to take more time and effort to learn.

I see two ways of approaching learning to code: thinking it through or just testing out every possible thing I can think of trying. Well, the latter is a big waste of time and the former just seems really tough sometimes. I can’t always see where I’m going with my code or predict what my code idea will do. Nevertheless, learning code requires using both strategies as much as possible.

I need to get better at predicting what code is going to do which means really understanding every object I’m working with and what can be done to that object. For example, today I got stuck on wanting to add a method onto the end of a refactored code block used on a previous method call. In some cases this works.

Let’s say I used the map method on an array and then I wanted to do something in a block that followed, then count up the elements in the array that had that something done to them. Using map, this would work because map actually returns a new array. If the method called before the code block doesn’t return anything however, tacking a method onto the end of a code block won’t pass. Good to know.

Pairing was a little easier today. Before we even started writing out our code, my partner and I discussed how we would approach working together. We also took this opportunity to share about our fears and concerns. This took a little of the pressure off us both. 

As for my coding, something big I learned today.. again …is that I tend to make things more complicated than they need to be. We spent over two hours working on the first exercise because I was making the problem too complicated. When the correct code finally came to me, I couldn’t believe how simple it was. As I reflect on this now, I see part of the problem as the anxious way I approach a new problem, like before I even look at the question, I’ve somehow ascertained that it will be so tough I won’t be able to work my way through it. 

Starting tomorrow I give myself permission to fear nervous but I am also acknowledging myself as an intelligent woman who can think clearly, especially when I am relaxed and centered, so that any problem can be broken down and solved. It’s time I really learned how to break things down piece by bitty piece. Too many nerves and unhelpful assumptions really just get in the way. 

0 notes

Dev Bootcamp Day 1 - Incredibly fun and remarkably challenging

The coding is tough. The pair programming is tougher. Good self-care? Maintaining that over the next 9 weeks is going to be toughest of all!

My pair programmer and I didn’t finish our core exercises until 9pm. I stayed to do one of the extra challenges and then had to go. I’m someone who needs 8 hours of sleep most nights and who prefers at least 9. 

Regarding the actual coding, I did a ton of work on the prep material so I felt like I was always on the edge of my learning but rarely panicked about what I was doing. It helped that my pair programmer today is someone whose already done the exercises once. I felt great at times too when I could really work out the code myself.

Learning to communicate while working on the code seems almost harder than writing the code itself. I noticed that when my partner let me take the lead I would type but not always talk out loud about what I was doing. That’s something I need to keep in mind. We both need to follow the code being written and know where it’s going. We need to be in constant communication about why we are choosing to write what we do.

Something I learned today that excited me? Today I learned about refactoring code using ternary operators, using a question mark and a colon to turn several lines of code into just one. Here’s an example of a ternary expression:

     a = true ? ‘a’ : ‘b’ #=> “a”

     b=false ? ‘a’ : ‘b’ #=> “b”

We were reminded, too, that journalling about what we learn has been shown to accelerate the learning process so I intend to blog at least once a day about something I learn. 

Now it’s time for bed…

0 notes

Ruby Review - Hashes

  • Hashes differ from arrays because they are unordered lists, the elements of which need to be called by their key names.
  • Hashes also differ from arrays because they require curly brackets versus square brackets.
  • Hash keys are also known as symbols. Symbols typically start with a colon {:symbol_name => “some_value”}.
  • Hashes take key_name / value pairs.
  • Consistency with hash key naming supports Ruby to use less memory because a key name can only be used once.
  • To change or add a hash element: hash_name[:current_symbol or new_symbol] = new_value .
  • Hash operations examples: hash.keys; hash.values - the values come back as an array; hash.has_key?(:symbol) - will tell whether the key exists; hash.has_value? - similar to the last operation but seeking values; hash.merge(into_this_hash) - the hash being merged will retain its values in the case that both hashes have the same symbols.


0 notes

Ruby Review - Arrays

  • An array is just an ordered list; list items are called elements or members.
  • An array can also be empty.
  • Arrays can contain numbers, strings, booleans, other arrays or hashes.
  • Arrays can be appended and when we want to know what’s inside an array, we can ask questions that tell us specifics.
  • Square brackets are used to create arrays.
  • When using the .inspect method the array items will be listed out just as the array is.
  • The index is used to find the values in arrays; index starts at 0.
  • In arrays, order matters. List items are referred to by their place in the list.
  • There are a ton of built in array methods to get info about the array or tell it to ‘do something’.
  • When counting items in an array, start at 0, not 1. The first item in an array is at place 0, the second item at place 1 and so on.
  • To change an array: array_name[place] = the_change
  • To determine the last element in an array using the index: the simple .length method works if you remember to subtract 1 from the length total. Subtract 1 because while there may be 12 items in the array, we need the index position that represents the last element; in this 11.
  • If I want to know if an array is empty use array.empty?
  • To list what’s in an array with commas in between each item and the brackets gone: array or array_name.join
  • To create an array from a string of words or letter or numbers, use string.split
  • To add to an element to array use array.push(“new_array_item”).
  • « can be used instead of push: array « “cats” or array « true.
  • Pop is the opposite of push and pops the last array element off the list.
  • Unshift works the same as push and shift works the same as pop but starting from the other end of the array.
  • Array concatenation - arrays can be added to one another to create a new array containing elements of all.