Discover Top Posts Tagged with #byebug

W1D4

Today I Learned: how to use Git and Byebug.

After review of the previous day's materials, we had a lecture on serialization of code, which is essentially turning code into a string that can be used. We discussed ways to serialize code using JSON and YAML; since we are using Ruby at the moment, YAML is more suited to our needs as YAML can convert Ruby objects. In addition, we learned how to use Git to save our work locally and how to share it via a repository online.

After we discussed Git, we had a discussion on the usage of Byebug to help us debug errors in our code. We had plenty of practice with Byebug today in our pairs.

With my pair, we worked on debugging code for a Sudoku game. There were multiple levels/clones of the Sudoku game code for us to debug with various bugs in each. My partner and I grew increasingly comfortable using Byebug and Git to save our work locally.

After we were finished with the debugging exercises, my partner and I worked on creating a Minesweeper game. We were able to use recursion, which was taught yesterday to help us check our neighbors/surrounding tiles/spaces. Our game looks great!

Pair programming today went very well. We both learned how to use Byebug, which I imagine will be an invaluable tool to us as we continue learning. Overall, it was a fun day and I feel that I am growing more comfortable with the material with each passing day.

#W1D4 #Git #Byebug #Minesweeper

Week 1 Day 4

Debugging day.

I felt like today was the most valuable day yet. I'm glad we had a day where we primarily focused on using byebug. I'd previously seen it in the readings and used it very superficially, but was relying on using 'p' in random places in my code. Byebug is so useful! I love being able to check values, set variables, and break code at any spot I want. It's such a powerful tool. The lecturer, Asher, stressed how much time we'll save in the long run by learning to be efficient debuggers and shortcut enthusiasts. I'm trying to make it a point to use my mouse minimally so I can get use to navigating around via the keyboard. We also went over git in the afternoon. It seemed straight forward, I just have to remember to push code frequently.

During pair programming, we worked through a debugging exercise by finding & fixing bugs. These exercises were enjoyable and satisfying to complete. It feels so good to finally squash an irritating bug. Debugging forces you to zero in on your code, which clued me into some interesting aspects of Ruby. For instance, I didn't realize before that the splat operator coerces values into an array. I assume this is how Ruby can take in an unknown number arguments.

Awesome Atom shortcuts:

cmd + shift + enter adds line above

cmd + delete deletes an entire line

option + delete deletes one word at a time

option + left/right moves one word at a time

Daily takeaway: Learn to debug efficiently; it'll save time in the long run.

#ruby #debugging #byebug #git

W1D3: recursion(recursion(recursion(inception?)))

Today was recursion day! Makes the brain start to hurt after a while keeping track of how many levels of recursion deep in the stack you have traveled, and what your return values will be. Not the way I’m used to thinking (outside of Christopher Nolan movies, that is!) but the harder you have to work, the more rewarding when you find a solution! I will say that I thought I had a much stronger ownership of the concepts when we were just in lecture than when I was trying to implement them myself, but had a good time talking through the concepts with my partner, sketching out diagrams of how we thought our programs would behave, and using byebug to keep track of all returned values. I wish we’d had time to get to the REALLY hard stuff!

#recursive #byebug #ownership

w1d2: catbang and byebug

We started off lecture with a quick and not particularly helpful review of yesterday’s solutions. The only problem Jeff went over from assessment00 was one of the only ones I actually finished, and while I’m sure he was going slow so that we could follow what he was doing, it made me feel even more like we were not given anywhere near enough time for it. The only other solution he went over at all was for the ghost game, which I never got to and so didn’t really mean anything to me.

The actual lecture was pretty good, though. It covered several things that fell into that uncomfortable “I know what result to expect from this but only because I’ve seen it before and not because I have any idea how it works” category, which was good. I like to know what my code is actually doing, not just what it’s going to output.

I definitely kinda felt like the weaker partner in pair programming today, but not so far behind as to be useless, and I definitely learned a ton, especially about debugging in general and using byebug in particular. We only finished the first part of the first project, but we did spent a huge amount of time on sort of tangentially-related things instead of really pushing to finish more.

We were in byebug for at least an hour throughout the course of the day. I’d barely used it before, so at first I was mostly just watching and taking suggestions, but I’d be willing to bet that by the end of the day Kyle and I were probably the two most comfortable people in the class with it.

We also made much better use of the TA’s than my pair did yesterday, which is good because that’s something I felt like I didn’t really take advantage of before. We spent a lot of time talking about vaguely on-topic things like class methods and what attr_reader/accessor actually do, which I’m still not 100% sure I understand, but I expect it’ll make more sense when it actually comes up.

I (I think it was me who actually typed it but I’m not sure) managed to create a tiny but absolutely ridiculous bug that presented itself as a no method error. What happened was I inadvertently wrote a method inside of another method, which caused the class to not recognize that it had that method available, and it happened that the same method name (display) is a method of the Object class which, among other things, calls the write method on something. So when display was called, Ruby couldn’t find it in the class we were in and went all the way up to the Object class and tried to use the display method it found there, which spit out an ugly error when display tried to call the write method in some way that Ruby didn’t like at all. So we got a no method error about a method that neither of us had ever heard of and didn’t seem to be part of our code at all. Our TA was pretty stumped as well until he eventually figured out that our class wasn’t recognizing the display method we’d written for it and then Kyle noticed it was defined in the wrong place. Apparently the next step in debugging it was going to be to start commenting shit out until the code ran again.

Anyways we managed to finish the first part of the memory game like 5 minutes after class ended, which was good because it was enough of a stopping point to feel pretty satisfied with the day. We certainly didn’t get as far as some pairs, but we might have learned more than anyone else.

Also, even tiny little minor successes are really satisfying when you’ve been debugging literally all day.

#appacademy #w1d2 #debugging #byebug #ruby

Ruby IRB 대용인 Pry의 디버거는 MRI 2.0.0 에서 동작하지 않습니다. MRI 2.0.0 이상의 버전에선 대신 pry-byebug로 디버깅을 할 수 있습니다.

현재 프로젝트에서 디버깅할 일이 있어, pry-byebug 페이지에서 사용법도 읽어볼 겸 자주 볼 것 같은 내용을 좀 긁어 왔습니다.

디버깅의 시작은 코드에 아래 내용을 추가하면 됩니다.

binding.pry

실행 명령

step: 현재 줄 코드를 실행하고 다음줄 또는 함수로 이동, 숫자 인자를 줄 경우, 여러번 반복함.

next: 현재 줄 코드를 실행하고, 현재 프레임에 다음줄로 이동(함수 안으로 이동하지 않음.) 마찬가지로 숫자를 인자로 줄 경우 여러번 반복 실행함.

finish: 현재 스택 프레임이 리턴할 때까지 실행, 현재 함수라면, 함수 실행을 마치고, 해당 함수를 호출한 다음줄로 이동.

continue: 프로그램을 계속 실행하고 현재 Pry 세션을 끝냄.

up: 스텍프레임 윗단계로 이동.

down: 스택프레임 아랫 단계로 이동.

frame 특정 프레임으로 이동, 인자가 없을 경우 현재 프레임을 보여줌.

break: 현재 파일의 줄 번호 또는 메서드 로 새로운 중단점 설정. 조건에 따른 중단 설정 가능, 다양한 플래그(flags)로 기존의 중단점 편집

break 예

break SomeClass#run # Break at the start of `SomeClass#run`. break Foo#bar if baz? # Break at `Foo#bar` only if `baz?`. break app/models/user.rb:15 # Break at line 15 in user.rb. break 14 # Break at line 14 in the current file. break --condition 4 x > 2 # Change condition on breakpoint #4 to 'x > 2'. break --condition 3 # Remove the condition on breakpoint #3. break --delete 5 # Delete breakpoint #5. break --disable-all # Disable all breakpoints. breaks # List all breakpoints. (Same as `breakpoints`) break --show 2 # Show details about breakpoint #2.

#ruby #pry #byebug #debugging

w1d5

Week 1 is already over!!

On Friday, we worked on an unbeatable Tic-Tac-Toe AI. During the exercises, lots of people in the class struggled with getting a specific method to work properly.

My partner, Alex, and I, decided to try using byebug for the first time to help debug the issue. We learned two important things from the extensive debugging process that followed:

1. Byebug is amazing.

2. Passing rspec tests does not necessarily mean that your code is bulletproof.

Byebug proved to be incredibly useful. We, were, indeed, like Neo -- jumping from line to line and watching how the variables changed. If it weren’t for byebug, we would definitely have missed our error when we watched one of the helper functions do something that it wasn’t supposed to do. At the beginning, we were reluctant to accept that there was something wrong with another method in the AI (”the spec passed, after all!”), but we eventually came to terms with it, found the error, and completed the project in no time.

Monday is our first assessment... back to studying!

#appacademy #byebug

w5d3

The day of REGEX is upon us. Byebug be thy name. Yesterday I had thought I got everything working since all the specs passed, but it turns out there were a bunch of regex related bugs preventing the actual website from running. Byebug to the rescue! I also implemented flash and flash.now alerts. I got a solution that works, but then I looked at the rails source code on github and was confused by the black magic going on in the actual rails flash hash.

#rails #byebug