#rubber duck debugging is a method of debugging code by explaining the code to a rubber duck btw

[i-want-to-do-things]

Rubber duck debugging

[jaybarou]

Since I've been asked this one multiple times I decided to put this one here! Why is the drama queen robotic mafia boss called something as goofy as The Duck?

Rubber duck debugging

In software engineering, rubber duck debugging (or rubberducking) is a method of debugging code by articulating a problem in spoken or written natural language. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line by line, to the duck.[1] Many other terms exist for this technique, often involving different (usually) inanimate objects, or pets such as a dog or a cat. Teddy bears are also widely used.[2]

🦆

So basically, it's because if you have problems with an AI, you tell The Duck.

And it was an obscure joke all along.

@cursio-neptune I'll answer right asap! <3

[indigo-scarf]

This is hsvh-hp. Can’t ask from my sideblog so EXCUSE THE ANON. Anyway, tell me all about drapple :)

WIP ask game

It was a crack treated seriously concept about Draco losing his mind in 6th year. It would start as using the apple to "rubber duck debug" the cabinet (a method of debugging code by forcing yourself to explain it to an inanimate object, a.k.a. the only piece of information I've retained from taking CS50x), and devolve into getting attached to the apple.

The biggest hurdle stopping me from writing it is having no idea how vanishing cabinets work or how one would go about fixing them because the magic in HP is just vibes (and maybe I could simply make it "just vibes" too, but I'd also have to figure out how to do that).

rubber duck throw (despair) ? (persevere) fixes it tower night powerful preservation spells came across in research for both cabinet and murder (did they have dark arts books - yes in the RS and you need a note from a teacher i.e. sneep the DADA teacher yasss) optimism when you come up with a new idea thinking it's ok it might actually work like gives you fresh wind, until you actually start trying it and it fails and the stress comes back

[aproblemforlater]

Week 9

This week, I will focus on integrating the ghost system with the leaderboard and its data class, so ghosts can be loaded from the main menu, and played in the next session.

After adding the extra members and methods I needed to add ghost data to this class, the data is saved as it was before, as the class data is saved without any extra input from me, which was nice to see.

I am feeling happy that I took the time to create a robust saving system which can take any type of class data, because this means it now doesn’t matter what I put in the classes which are saved, as long as they can be serialized, it will work without any extra work from my behalf.

From here, all I now need to do is have the data be loaded from the main menu. I already have an options class present in the main menu, and in the main scene which save and load data, and the instance is static. This means that I will not have to introduce any more hard dependencies to any scripts, and I will be able to save and load ghost data using the options class instead. However, I do not want to be copying data. The ghost data is a large size, and copying in any case will take time. Since it is already saved through the leaderboard, and is saved In an array which is organized in the order it will be shown in on the leaderboard, I will be able to just store an index number of the data I wish to load.

When the player Is on the main menu, if you go to the leaderboard, the data which is loaded and organised is displayed on the screen. The buttons next to each entry only load if ghost data for that entry is available, and because the leaderboard is organised and displayed how the list is indxed, when a “Load Ghost” button is pressed, It passes its index value to the options class instead of the raw data. Then when the main scene is loaded into, the ghost replay class will access the optiom instance, which loads the saved options data at construction, and loads the ghost data at the index which was saved.

This system works, but I feel it is quite complex for what it acheives, and we are now bringing in separate systems for a single int value. On reflection, I could have saved this index value in the leaderboard save data class, and this would make a lot mores sense, since the data has to be loaded directly into the ghost class anyway.

Taking a step back and reviewing my implementation of what I create is becoming a useful tool to have as well as iterative development, as although iterative development yields quick results, it does not highlight improvements that can be made to the readability or layout of the code. Explaining my system, a form of Rubber Duck Debugging, is helping me to improve the code structure, and simplify design by explaining how we get to the end result, and finding optimizations to reduce complexity.

We have a testing session again next week, and me and the team have been discussing what we would like to try and get in the game for this time. One big taget is having a production level track in the game instead of the testing track I made for the first testing session. This should be a task for the artists, so I will not be taking part in this, but the feedback about the track we received in week 5 should be helpful in influencing the type of design we follow.

Another target is to get split screen integrated into the game. This task has been taken by another member of the team, and they said they would focus on the implementation of introducing a new object, new camera and try to get it working. I am skeptical for this step, as I am almost certain that the systems I have been developing only accomodates for single player. I am expecting my job to be a lot of refactoring, and so I am going to wait for the splitscreen functionality to be developed, and then use iterative development to work through the issues, and improve the systems to be able to manage multiple players.

Summary:

Ghost system has been integrated into the leaderboard data, and Is able to be saved and loaded with the leaderboard if It is a valid entry.

Option to load a ghost can be used on the leaderboard at the main menu, which is then used in the scene.

Taking the time to modulate and create sets of data classes is becoming very useful now I am developing more things which would benefit from being savable, and are usable by different classes.

On reflection, the implementation of this system could be improved by changing the way a ghost is saved and loaded, and would reduce dependencies in the system.

The target of split screen is being discussed, and I am apprehensive about the changes to the current set of systems we have, and how this will affect stability.

[altercontrollerproject]

Rubber duck debugging

In software engineering, rubber duck debugging (or rubberducking) is a method of debugging code by articulating a problem in spoken or written natural language. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line by line, to the duck.

Rubber duck debugging so far has helped me set up the test that I ran for the audio input that would be used in this project. The test was successful and the duck helped me realise I hadn't referenced correctly between blueprints.

[seekers-who-are-lovers]

I wonder if Rei is using the duck as a code for “rubber duck debugging.”

According to Wikipedia: “In software engineering, rubber duck debugging (or rubberducking) is a method of debugging code by articulating a problem in spoken or written natural language. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line by line, to the duck.[1] Many other terms exist for this technique, often involving different (usually) inanimate objects, or pets such as a dog or a cat. Teddy bears are also widely used. Many programmers have had the experience of explaining a problem to someone else, possibly even to someone who knows nothing about programming, and then hitting upon the solution in the process of explaining the problem. …. By using an inanimate object, the programmer can try to accomplish this without having to interrupt anyone else.”

He talks to the duck in order to explain his dilemma and then he, in turn, will discover the solution by himself.

Writers do this too.

Just a thought.

[kokomalls]

give me can't sleep love

i want that can't sleep love

the kind i dream about all day

the kind that keeps me up all night

give me that can't sleep love 🎶

- can't sleep love

hanako hAUlloween day 6: teen school drama

someone get me out of the timeline where amane likes furries and into the one where he likes nene

extra artist notes below:

rubber duck on amane's wardrobe - people who often program carry around a rubber duck as a method of debugging their code when there is an error they can't find in their massive block of code. the method goes that the coder reads out and explains every single line of code to the duck until they discover what the error is. i thought it would be a nice fit since amane is implied to be into robotics in this au.

vega and altair: the two constellations associated with the tanabata story.

the lovers / three of swords: two tarot cards. the lovers often represent lovers, relationships, or harmony. the three of swords represent heartbreak, loss, or emotional grief. a red string runs through each card.

[leafonsidewalk]

How to Debug Using a Duck

Rubber duck debugging, or rubber ducking, is a method of debugging code in software engineering. The term can be traced back to “The Pragmatic Programmer”, a book by Andrew Hunt and David Thomas detailing a programmer who carries around a rubber duck and debugs their code by explaining it to the duck, line by line. 

Steps: 

Get a rubber duck (preferably a bath-time duck, but any size is okay)

Start explaining the code to the duck making sure to read each logical step out loud and in detail while pointing to the screen so that the duck knows which line you’re talking about

Continue to go through your code until the solution to the problem is found

The main point of the exercise is to have the developer slowly and carefully explain their code out loud, line by line. Since we think faster than we speak, verbally explaining the code forces the coder to slow down and, under the assumption the duck knows nothing about the code, the coder also has to be precise in their explanation which helps them learn and become more efficient in programming. Pointing to each line of code makes them review the syntax and logic right under their finger, making it easier to see where what the code is doing differs from what they think it’s doing. 

Sources: What is Rubber Duck Debugging? - Kenzie Academy (snhu.edu), Rubber Duck Debugging (rubber-duck-debugging.org)

[eligos-venator]

I'd like to hear more about the spooky gargoyle in Eligos's office - where did he get it? Also, not anon because I'm rebellious like that! :3

For Eligos, it's a comfort item of sorts. He found it at an art gallery, and immediately purchased it. The artist told him it came to him in a dream, and Eligos didn't think too much about it when deciding to buy. As far as he's aware, there's no special properties in it. After an accident with a remote weapon going haywire damaging the statue and knocking it off the pedestal upon which it originally stood, Eligos needed to ship it off for a time to get it repaired before installing it once more in his workshop. The stone gargoyle now has a weave of thin golden lines crossing it with no particular pattern, beyond that the weave is the most cluttered along the right arm and claw. Kintsugi was the method used to repair the damaged statue, as Eligos didn't want to give up what he already had.

For the garlean, the statue represents the height he aspires to climb to, and serves as inspiration and comfort both. Having no close friends or people he could rely on for the past decade of his life as he traveled, Eligos came to lean on his namesake's legacy as a way to motivate himself to push forward, and based how he conducted himself and his business off of the goal of emulating his namesake. Being entirely used to being treated poorly by those around him due to his mixed blood, he sees no issue with taking comfort in the thought of gaining the acknowledgement of the devil whom he emulates, having no compass left to guide him beyond the name he bears and the gleam of gold.

In a practical sense, the statue serves as his rubber duck when Eligos tries to work on debugging any errors in the coding of his more advanced equipment. He has a stool in his workshop upon which he will seat himself by the monitor with the malfunctioning gear in hand, explaining it and the code it runs on until it clicks where Eligos made the error. It doesn't serve any other functions though in a practical sense, and is the only bit of art and personal touches one might find in his otherwise barren, cold workshop.

Thank you for the ask @wildgirlcinna

[dianaburnwood]

of course I'm talking about these ducks) which 47 uses as bombs

Ducks have been a running joke in Hitman games since Codename 47, when an asylum patient asked 47 to help him find his rubber duck. It grew to the point where 47 now has rubber duck explosives. 

I don’t know why they first appeared in the game, but my best guess is it’s a dev joke nodding to the rubber duck debug - a method by which you explain a code/design problem you’re having, line by line, out loud, to a rubber duck (or any inanimate object). By doing so, you usually discover the source of the problem yourself. It does work well lol  

[take-a-bug]

a human caretaker who does programming might at one point ask one of the bugs help them by rubber-duck debugging, which is when a programmer who is having a problem with their code explains it verbally to a toy duck to help them figure out the issue. the human explains the code to one of the bugs even though the bugs dont know how code works. it works tho, and it becomes a regular thing in the house, with quirrel and monomon voluteering to help most of the time (though pk is curious abt it too)

Some of the bugs like to sit and listen to the human grumble to themself as they code. It’s a surprisingly effective method of learning how computers and coding works, especially when the human hits a bug (the computer kind, they explain. Not the alive-kind). Monomon eventually insists on the human teaching her written English (or whichever relevant language) and giving her and Quirrel official computer lessons. Pale King eavesdrops on the lessons too, as well as the occasional curious vessel, though they always get bored before learning much.

[the-entangler]

In software engineering, rubber duck debugging is a method of debugging code. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line-by-line, to the duck.

[mhopwood-bct]

Reflective journaling

The introduction to Creative Technologies has been an effective tool for me in making the most of the work that I have in my time with BCT so far. It has shaped a change in mindset that taught me not so much what to do, and more how to do it and how to improve upon it and myself. This has been most evident during one scenario in particular, which by using the Kolb Cycle I would like to cover in a little more depth to shed light on what ICT has done for me. Experience

The experience that I want to cover was less of a specific activity, and more of a “eureka” moment which I want to reflect on how and why it happened, and how it has affected me in the time afterwards. This was during our first studio assignment, Cards for Play. The majority of the time that we spent during the early stages of the project were discussing and planning. This was comfortable territory for me; however as happens without the further stages of the Kolb cycle or any effective design process, we became very stuck. Then we started play testing, and this, for me, was the eureka moment. Immediately, after only two tests, hurdles that I couldn’t have foreseen in my head became strikingly obvious, and issues that I thought would occur turned out to be very minor. Analysis

 This was a great insight into the sheer power of iteration and critical observation, and what an effective and efficient tool it is. Coming into BCT, I can look back and realize how internal my methods were. When presented with an idea or a hurdle that needed to be overcame, my first response would be to sit and think. And once I came up with a solution, I wouldn’t move on, and would continue to think several steps ahead. This in hindsight did nothing but reveal non-existent or irrelevant hurdles. Having been shown the Kolb Cycle, and used it in recent projects, I now know that this stage is the very first of four, of which I would never move on from and become stuck, unaware of how to expand on the creative process that I had, as my process was a closed loop, rather than a repeating and iterative one. (Jin and Chuslip, 2005) state that “Creative design seems more to be a matter of developing and refining both the formulation of a problem and ideas for a solution, with constant iteration of analysis, synthesis and evaluation processes between problem-space and solution-space” Based off this, I would say that my biggest weakness before ICT was my ability to identify problems, which by this statement is a key step, and the concurrent nature of the two and how they prompt each other naturally encourage iteration. I personally find this statement very accurate as once the testing stages of our project began and problems became known, it became many times easier to squash them out one by one, and our changes were significantly more effective as they had a distinct purpose. This was me breaking into the second stage of the Kolb cycle, to observe and analyze.

Reflection

 “Reflection can be seen as a creative process closely linked to imaginative thinking as it involves re-experiencing something that happened earlier, projecting into the future or transforming someone or something through action learning” (Collier, 2010).  Reflection is a concept I have always understood, however have never put into effect the way that I do now. Being a creative process in itself, creative reflection has been imperative to the work I have done so far due to the fluidity of a concept that is under development, and the ability to alleviate assumptions that may no longer be relevant or true. From the very first week ICT has been slowly shaping a new mindset in all of us that encourages us to challenge our own ideas and be critical of others and ourselves in a way that allows us to learn and develop our understanding. The use of our blogs has been a significant asset to this. Similar to “Rubber duck debugging” in which programmers will explain code to a rubber duck and often in doing so find solutions to their problems, breaking down and writing out our work in a way so that other people would be able to understand it creates a shift in perspective that can reveal ideas, holes and insights that were not apparent beforehand. Another specific example in where ICT has allowed us to reflect in the same way was our vlog assignment, given to us right from the get go. This was more aimed towards personal reflection; however had the exact same effect as we were encouraged to convert our thoughts into a different medium, again giving us the opportunity to expand our understanding further on a topic that we already thought we knew. However this is not the only advantage of this process. As designers, we set ourselves assumptions and our own interpretations of something, and in breaking down our problems and solutions into a way that can be understood from a third person perspective, some would argue that we bring ourselves closer as designers to the core experiences of what we are creating and how it may be perceived outside of the design process, as  “The reflection conducted in different stages of the project provides primary material for communicating and sharing of the experiences related to the project” (Mäkelä, Nimkulrat 2011). Through ICT, iteration, and reflection, my creative process has been naturally guided into something that much closer resembles Kolbs experimental learning cycle, and through this process and further reflection I will hopefully be able to further refine and improve upon this and how I utilize it to achieve my goals. References

 Yan Jin, Pawat Chuslip 2006, “Study of mental iteration in different design situations”

Kate Collier 2010, “Re-imagining reflection: creating a theatrical space for the imagination in productive reflection”

Maarit Mäkelä, Nithikul Nimkulrat 2011 “Reflection and documentation in practice-led design research”

[the-real-tonystark]

Hey, Tony! I heard that computer coders use something called the "rubber duck method" when they're having problems debugging a bit of recalcitrant coding. Apparently, they get an actual rubber duck, sit it on the desk and explain the code to it line by line. You ever use this method? If so, do you use an physical rubber duck or a holographic one?

I have the Peter Parker method. I sit and talk it over with Peter.

[jammedmuses]

What is a debug duck??

According to Wikipedia:

"In software engineering, rubber duck debugging is a method of debugging code. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line-by-line, to the duck. Many other terms exist for this technique, often involving different (usually) inanimate objects, or pets such as a dog or a cat.

Many programmers have had the experience of explaining a problem to someone else, possibly even to someone who knows nothing about programming, and then hitting upon the solution in the process of explaining the problem. In describing what the code is supposed to do and observing what it actually does, any incongruity between these two becomes apparent. More generally, teaching a subject forces its evaluation from different perspectives and can provide a deeper understanding."

Basically, anything or anyone a programmer may use as an outlet to backtrack on their coding problem by explaining it to them until they realize the solution through the explanation they were giving their “debug duck”.

[ruwinhimself-blog]

Day 30 - Debugging

Today we’ll be talking about debugging in Unreal and the best practices that are associated with that. So let’s start with the most basic form of debugging.

Rubber Ducking

A reference to a book in which the character caries a duck around with him and uses it as a tool to force him to explain the code logically, step by step. This can obviously be useful if you’re trying to find stops or bugs in your logic.

Print String

The bread of butter of debugging. Super versatile and quick to set up. Printing a string can get you information about whether or not your code is working quickly-- and you can get it to feed you variable specific information. This can help you narrow down the possibilities and hone in on the bugs.

Draw Debug

You can draw debug just about any shape or size.

This is incredibly useful for nailing the behavior of an object. They often have 1-for-1 plugins for trace functions.

Console Commands

stat game

Checks overall blueprint performance

Dumpticks

Checks all ticking actors

stat rhi

stat memory

stat scenerendering

stat engine

Shift+L to Toggle All Stats

Output Log

The output log is a great way to tell exactly what is throwing warnings or errors and where, post gameplay.

Breakpoints

Breakpoints are a great way to step through entire methods to see where issues lie at runtime, and in a way where you can pause and unpause gameplay at any time. They are used in C++ as well.

For example, when this particular function is called, it will pause the game and let you take a closer look at what is going on within your code.

Blueprint Debugger

Stack trace allows you to print the entire stack flow of a method or function that is plugged into it to your debug and output log.

This is quite useful when you need as much information about what is happening before something is called.

Blueprint Automation

Tests your logic

Prevents mistakes

Reduces load on QA testing

Runs automatically through project launcher

Blueprint automation is an extremely complex system that plays your game automatically up to a point and collects data on it. This automation can automatically play and stop the game, so it essentially runs itself to gather data for you.

And those are the most helpful general debugging tools!

See you tomorrow!