RubyConf Randomness: Other things I learned that weekend

This post if all about the other random things I learned at RubyConf. Just as a note to begin, some of these items are talk-related, others are just literally random things I learned. In order to learn, I needed to ask. Don’t shy away from asking about a joke or tv character. It’s not embarrassing to even ask the small questions...I’m new to tech and therefore I don’t understand all of the star trek references or ruby jokes. Ask them!! Then you’ll be able to laugh at them in the future! It’s the little things that make a big difference.

1. Koybayashi. There’s more than one. I have a confession… I love eating contests and the sport of competitive eating. Yup, you read that correctly, eating contests. The best part of every year for me is the Nathan’s hotdog eating contest every July 4th. I love the commentators and the competitors, I know all of them and their stories and their past records. One of the most famous major league eaters is Kobayashi. He held the world record for number of hotdogs eaten for a long time until Joey "the jaws" Chestnut came onto the scene. Now, during Evan’s talk about Redis and Recommendation Engines, he had a slide about Kobayashi. This slide had no hotdogs and I was very confused. Turns out, there’s more than one famous Kobayashi. The Kobayashi he was referring to was Kobayashi Maru, (Straight from Evan!) a fictional test administered to Starfleet cadets in Star Trek. Cadets are evaluated on how they handle failure. Now that slide makes much more sense both in slide content and in placement within the presentation.

2. Talks I wish I had gone to. There are two talks that I really can’t wait to watch. These are Pat Shaughnessy’s Garbage Collection talk and Dave Copeland’s talk on branching, nil, and attributes. I saw lots of cool notes about these two sessions on twitter and heard great things from people who were at those sessions. Another note on talks, I thought the lightning talk by Andrew Harvey was really good. If he posts his slides, you should definitely check them out.

3. I didn’t do a full write up on notes from Day 3, session 3 about being an open source maintainer. I didn’t have many notes but hopefully this topic will be more relevant to me in the future. I wanted to put some little notes about it here though. Some key points I noted were the idea of rewriting the history, triaging a pile of issues when you first become a maintainer, and taking responsibility.

4. I learned about like 15 new languages while there. Seriously, who knew there were so many programming languages?! Some languages I heard of included poison, Dylan, and whitespace. I intend to fully ignore these until I’m a little more comfortable with ruby but I can’t wait to be at the point in my developer education where I can play around with these weird random languages and easily understand what’s happening.

5. The last session was a fireside chat with Matz. At some point someone asked a question about someone called Nobu and everyone laughed. For those of you who also didn’t get it, here’s what everyone was laughing at. There is a guy named nobu who has the most contributions to ruby and the running joke is whether or not he’s a bot or a real person. Apparently he’s a real person. Next time, I’ll be able to laugh too

6. I arrived late to board game night and therefore didn’t really jump into anything, but there were some really cool games being played! If you were there and remember any of the names, please leave them in comments! I’m always looking for new interesting games.

On a final note, I just want to say thank you to everyone that I met and had conversations with while at RubyConf! It was really fantastic to meet so many people doing so much cool stuff. And thank you to the organizers who put together the scholarship program! I wouldn’t have been able to go if it hadn’t been for that opportunity.

Hopefully I’ll see everyone in San Diego next year!!!

Are you good code or bad code? - Day 3, Session 4

This was the last session of the conference but fortunately, also one of the most fun sessions! The session was moderated by Matt Aimonetti and featured a panel discussed if bad ruby code exists. The panel was comprise of Aaron Patterson, Bryan Liles, and Bryan Helmkamp. If you have a chance, WATCH THIS TALK! As opposed to being a presentation, it was actually a really interesting discussion. I have a few notes from this session that I’ll write below but a lot of the conversation was mostly about questions to ask yourself as a developer when you’re writing code. Additionally, the panel members talked about their perspectives on good code, bad code, get it done code, etc. Overall, they were all really good points for me to continue to keep in mind as I work on different projects and in the future, work on more complicated projects.

First, there was a discussion about what is good code. The consensus seemed to be that good code was more testable, more maintainable, and more extendable. Most people seemed to settle on the fact that there is no bad code, but there definitely is code and better code. To this point, Bryan from Code Climate talked about the static analysis of code which helps people make more informed decisions. He hopes that the code climate process is helping to make better coders and also help determine what is better code.

Second, there was some discussion of “the rules”. I found this really interesting since I’m still learning the rules and the rules are important. When you’re first learning, it’s important to know the best practices and what the rules are. The goal is to get to a point where you can decide in an educated way if you want to break that rule or group of rules and why.

A question came up about refactoring and when you should take the time to look over your code, refactor and make those changes. The panel discussed always asking themselves the question of “how long would it take me to take this code and make it easier/better?” (easier/better meaning easier to work with or in). When the answer is around a week or longer, you’ve probably gone too far without pausing to refactor.

One suggestion based on this is when you’re working in a class, decompose the things into composed methods. In other words, factor out methods into smaller methods.

But seriously, watch this talk. It was entertaining, humorous, interesting and I feel like made me a better developer in a very different way than most of the other sessions.

The most important things I took from this talk:
1. Good development is knowing why versus how
2. A good developer knows the rules and also knows when to break them
3. Write the best code you can in the time you have
4. Focus on moving forward. Be a better developer today than you were yesterday, be better this year than you were last year, and so on.

Program on my iPad?! - Day 3, Session 3

TL;DR: have you ever programmed on your phone or iPad? I haven’t but now I totally want to.

I thought this session was plus/minus (sorry Charles Wood! I still love Ruby Rogues!). My main issue with the talk is that he showed this awesome demo of actually being able to pull up the command line on your phone or iPad in order to actually program but didn’t really go into how one would accomplish this.

Charles talked about the toolbox he uses to get his development machine in the cloud. Primarily, he uses SSH, Digital Ocean, tmux, emacs, Github, and Chef. First, the SSH is configured and public/private keys are created. You can create one key for each machine or a single key for all your machines. He discussed Digital Ocean as the server he uses.

Second, he prefers to use TMux. I’ve heard a lot about tmux for pairing and how it’s a great tool when you want to pair with someone (I’ve yet to use it). For this case, however, he also liked it because you can pick up where you left off instead of having to restart something or get back to where you left off. Additionally, you can do multiple or split screens which is useful.

I didn’t write down any notes about emacs, github or chef since I have a bit of a background on those (if you ever want a great presentation on chef, hit up Nathen Harvey… he did a 10 minute “what is devops and what is chef” talk for Rails Girls a few months ago that was so amazing).

I jotted down a few notes about security, since that seems like an important issue when you’re using a phone or ipad to log into your development environment. These security suggestions included turning off the root ssh, using public/private only, having a firewall, using something like proXPN (a tunneling service) and using sudo.

The main question I had after this session was “ok, but now how do I actually get this working?!” He did a good job explaining the tools, some of which I was familiar with, others not as much and while all the tools at the end sound great. I’m still not quite so sure how they all get pulled together to let me program on my iPad. After the session, I spoke with Conrad a little bit about this and he pulled things up on his phone (which again, was really cool) and I think I understand overall how I would go about doing this. It mainly has to do with setting up the SSH and a server and I think everything else stems mostly from that. The basic steps are to 1. set up or have access to a server. 2. Install with a package manager onto the server. 3. Ssh into the server. 4. Then you have an ssh client for iPhone, like prompt, which is a terminal emulator for ssh. (I’m a little unclear on that last part, so if you do want to get into this, I’d suggest taking the basic tools listed above and then doing some additional research on the actual setup).

Encouraging new Software Developers- Day 3, Session 1

For this session, I went to Kinsey’s session on becoming a software engineer. Kinsey is a newer developer and did a great job on her talk!! The talk was closely related to my lightning talk and discusses apprentice programs and what has really helped her become a software engineer along the way. Among other things, she talked about how Thoughtbot’s apprentice program really helped her learn and grow and discussed ways other companies can think about apprentice programs.

TL;DR: More interesting thoughts on mentorship and qualities of an effective mentor and my personal opinion on the proliferation of bootcamps.

Kinsey spoke of outreach and how the RailsBridge program truly changed her life. For me, my first introduction to coding was through Rails Girls so I agree that outreach and new programs coming into existence are important in order to expose people to what they can achieve. She also spoke about mentorship and the importance of that (which I obviously believe in). She noted some important aspects of an effective mentor are someone who can explain complex concepts simply, someone with an awareness of both themselves and the mentee, and finally, someone who has patience.

Finally, she spoke about her progression and the tools she and Thoughtbot used to help her grow. These included weekly retrospectives, pairing, and empathy. This talk was a great talk. I think the room was mostly filled with people who do want to mentor and want to help support newer developers which was great and the room was pretty filled, showing the level of dedication in the ruby community to support each other and help newer people just getting into the industry.

One side note that I’m compelled to mention related to new apprentice and bootcamp programs opening is the recognition that not everyone can do one of these programs. I think these programs are fantastic and I’ve met great people who have been a part of these programs. One challenge I’ve seen, however, is the expectation that if you haven’t done a bootcamp or apprentice program then you’re a riskier candidate for a job. Recently, when I talk about learning to code on my own, everyone asks me about participating in a bootcamp program, especially given how many are opening these days. These programs, while increasing some of the diversity concerns in the technology community, are still out of reach for many. A bootcamp’s tuition and living expense, as well as the requirement to move someplace for a few months can be out of reach for many. Oftentimes being part of an apprentice program requires those same sacrifices especially since often you are expected to stay in the same area after a bootcamp or apprentice program. There are merits to learning in a bootcamp-style environment however I hope those of us who have taken a different path but put in the same amount of time and dedication will still be considered as strong candidates for the same companies recruiting new hires out of these institutions.

Keynote: Code StoryTelling

The third day’s keynote was pretty interesting. Ernie Miller was talking about writing code and particularly writing ruby. The main premise of the talk was that your code should tell a story. In order to tell that story, things should be clean and clear. I learned lots of new terms and extensions of terms I already knew. A good way to tell the complexity of code is through branching. Branching shows how complex code is by showing how many branches it has. Branches are determined by places in which code could go more than one way. For example, an if statement counts as a branch because it shows code choosing one path or another.

Earlier in the talk, he spoke about rules of class macros. Classes should be easy to understand, order independent, free of branches, show what and not how, and idempotent. He also talked about callbacks. I didn’t previously know that there were so many different types of callbacks. There are reverse callbacks, around callbacks, and skip callbacks.

The final term I learned was prepend. Prepend relates to include and extend, but different. Prepend is related to include but in include, methods on the class are a higher priority than methods included from modules but prepend changes that! When you use prepend, the priority order changes so you can say prepend A for example and then A would be a higher priority than the other methods in the class.

Obviously this talk had a better flow than the notes presented here. He went over a lot of different ways to write ruby and styles. I just took notes on the terms I didn’t know previously and wanted to look into after the talk. Fortunately for everyone, the slides are up! https://speakerdeck.com/erniemiller/thats-not-very-ruby-of-you

UML: not just random letters - Day 2 Session 3

On day 2, I didn’t got to the second session because I was busy having an excellent lunch with the other ladies at the conference thanks to DevChix for organizing and sponsored by Thoughtbot! When I got back, it was time for session three. I wasn’t sure what to attend for session three (day 2 in fact was much higher level, I thought than day one so I was often choosing between sessions where I didn’t really understand any of them so it was a little bit flip of a coin, but the sessions ended up being really interesting). I ended up at The Big Picture with Jim Weirich.

TL;DR: UML can help diagram code which helps programmers see it and organize it with more clarity.

The Big Picture was all about UML which stands for unified modeling language. An initial warning, UML is a visual representation so I’m writing about some of the information but in order to really get the full picture and idea of what Jim discussed, I think it will be necessary to see the diagrams and models alongside the explanatory information.

Moving into the talk, there are three primary ways that you can use UML. You can use it to sketch a process. You can use it as a blueprint and finally you can use it as a programming language. Jim talks about using it primarily as a sketch. The first example he discussed in terms of explaining usefulness was showing dependencies. When you diagram something, you really think through the code and know what your code depends on. This is shown visually via the direction of the arrows. The direction of the arrow is the direction of the dependency. You can also use this diagram to break up certain sections of the code so, at one point, on the example, the controllers were outside of the box (in red) and the application was in the green box (see, this is where seeing the diagram is obviously useful).

One of the primary examples discusses was a sketch of Rake. Rake has few classes, but the classes that do exist contain lots of methods. There is no rules class in rake. There are also no domain specific locations in rake. The application is rake. Within that application, namespaces exist and the scope is constantly changing as you define a task. The file tasks ignore scope. I had never thought about the rake task in this way and broken it apart with this methodology so it was interesting to see the task essentially pulled apart into the different commands and components that comprise it.

There was a brief discussion of object diagrams and how it is important to keep in mind that an object diagram captures how an object looks at that exact time.

He then talked about another use of diagramming when talking about creation. It related to creating a process, but more importantly he used an AR Drone to demonstrate it so pretty much all my focus went to that leaving me with little/no notes on what creating a process actually means and why this methodology is useful for it.

Next we covered dynamic engagement which is a state diagram. In this diagram, you have a start state (represented by a black dot). Then the arrows represent transitions which happen with a trigger that make an action happen which finally switches the state.

Finally, we discussed interactions which are sequence diagrams. My notes for this part are a little shady but sequence diagrams are like object diagrams but with more lines and different lines. The diagrams show sequencing calls and are timing related.

Summarily, I can see where diagraming out code is interesting and useful. After this talk, I also heard others discussing how UML is a waste of time, which I can understand as well. I think in certain scenarios diagramming and utilizing UML could be very helpful and useful but in others, I can understand how it wouldn’t make as much sense.

Day 2 begins at RubyConf

So there’s this thing and it’s called JRuby and it’s like Ruby but it’s not Ruby. The talk was given by Charles Nutter and Thomas Enebo. This session was really interesting, at least the first part. I’ve never used JRuby before and didn’t really have a sense of what it was. The second part of the talk went into some more specific features and functions that will be added for the new release – that part was less interesting to me because I had never used JRuby before and therefore what I should be looking forward to in future releases didn’t really matter to me, but the first part of the talk was all an introduction to JRuby, what it is, what it does, and how it works. This, combined with some additional time and explanation with Conrad, really opened my eyes to the variety of different things going on in the Ruby world that are related to Ruby but not exactly Ruby.

TL;DR: JRuby does a lot of interesting things and I learned terms like JVM, jit, bytecode, and concurrency.

So, what is JRuby? JRuby is Ruby on the JVM (Java Virtual Machine). It is ruby implementation written partially in Java. It isn’t yet compatible with Ruby 2 but will be soon. JRuby is a different version of ruby entirely so you can use RVM to toggle between versions. Having Ruby on the JVM means that everything in the JVM is available to you. Essentially, this is really useful and cool because having the JVM available means that you can utilize Java libraries in your ruby code.

They then talked about garbage collection (more on that later) and jit runtime. Jit is a compilation called just in time compilation. In jit, when you run the compiler, you get an intermediate file (called bytecode) but the file isn’t optimized. So when you run Java, it takes the machine code and turns the parts you need into optimized code. Normal Ruby doesn't compile into machine code so JRuby runs like regular ruby but behind the scenes, it does a bunch of more complicated stuff. Traditional compilation happens when you run the compiler and get a binary file, not bytecode. This bytecode helps reduce overhead and they are currently working on improving the optimization even further in newer version of JRuby. The need for optimization comes from the longer setup time. Once the JVM is set up and running, it can be really fast (because it only optimizes pieces of the code as you need them) but it takes some time to get up and running.

They also talked about concurrency and parallelism. Concurrency means that is you have 100 users, then you need 100 way concurrency which is directly related to the amount of spacing (memory) you need at a given time. When you use threading (available in JRuby), it saves the amount of memory you need to use and therefore the amount of money you need to spend. This is also related to parallelism. Threading is not very commonly used in Ruby but to go into a little more explanation threading means instead of running 10 copies of the ruby code, you can run 1 copy of the code with 10 threads of the code. Related this, they talked about the thread-safe gem, hamster gem, and atomic gem. They also talked about shoes which I did some additional research into because it looks cool. Shoes is built using JRuby. It’s basically a gui (graphical user interface) environment which means it’s a way of writing graphical applications in ruby so that you have a user interface and you can so applications and not just web apps.

Now, back to garbage collection for a moment. JRuby has the best garbage collector. So what does that mean and what is garbage collection? Garbage collection runs code in your code. Ruby automatically throws objects away when you’re not using them in order to help with memory. Ruby marks items being used and tosses those that aren’t used… this is called mark and sweep. The JVM has a good garbage collector because of the way it optimizes the code (I think). For more on garbage collection, check out Pat Shaughnessy’s talk once it’s up on Confreaks (I missed it too, but it’s one that I definitely intend to listen to once it’s posted. I heard it was really good).

Finally, this talk about JRuby made me curious about the other stuff I had heard about… like CRuby, MRuby, Rubinius and what use cases were. A frequent use case for JRuby is when it is used to write a JRuby wrapper around Java code. CRuby is another name for MRI which stands for Matz Ruby Interpreter or the main documentation for the Ruby beginners are most familiar with. MRuby is a new version of a ruby-like language. Finally, Rubinious is like PyPy which lets you write python in python. Rubinious lets you write Ruby in Ruby which uses less resources and runs the ruby code faster.

Onto Session 2!

I fear I won’t be able to process everything and get it in a post before I start forgetting what my notes mean! Expect rapid postings in the near future.

Onto Session 2!

TL;DR: databases.

This session was about the Zombie apocolyse and data structures with Casey Rosenthal. I knew walking into this one that it would be a little over my head but after a post session debrief with Conrad (my guide) that helped frame database structures in general, everything clicked! I’m also just now starting to really get into database structures and understand more about how they work, how to work with them, and what are the ways you can structure different data types within databases so this ended up being a great session for me to be in. Also, it was about a zombie apocalypse so it had to be good. Let’s start from the basics. There are two types of databases, SQL databases and NoSQL databases. NoSQL databases are essentially anything that isn’t a SQL database. NoSQL databases can also be known as distributed key value databases. Examples of these databases include MongoDB and Riak. SQL databases include MySQL, SQLite, etc. There are a handful of differences but the main difference is that SQL databases are based in table modeling. SQL databases can be a bit more flexible if you have similar types of information coming in all the time, but they can also be harder to scale. SQL databases are also good as long as everything is on one machine because they are safe, have lots of features and have many other good aspects but features these same features are hard to implement once you are running on many machines. Why do you need to move to many machines instead of having just one machine? Because you can’t read the information quickly enough when there is a lot of it (essentially, the queries start taking too long and you need to split the information onto more than one machine). Finally, SQL databases enforce the structure. If you use a SQL database, all of the tables in the database require the same information. In a NoSQL database, this isn’t the case. NoSQL databases are designed to they can start as one thing but easily scale to become larger and hold different types of information. And because there isn’t the same table structure, it can be easier to store lots of different types of information. So, when using a NoSQL database, you don’t have to use commands like rake db:migrate because there are no data migrations (yeah, that kinda blew my mind and it was also where the whole rest of the talk suddenly clicked into place for me). AND there’s no schema file! A NoSQL database has tables but they aren’t specific so they’re called connections instead of tables. The downside, however, is that you can’t tell exactly what’s in the database unless you pull all the records

So, back to the actual talk…when thinking about what type of database to use, it’s important to think about how the information will need to be presented in the end. This was an idea that continued to surface throughout the talk.

Some important terms I learned when thinking about NoSQL databases (and databases in general) were high availability, strong consistency, and partition tolerance. High availability means you can connect to any part of the system and you can both read and write all the data. So, for example, if you have 3 different silos that each keep information, the databases are kept in sync with one another so that you can access all the same data from any of those silos. In other words, if a server crashes, the database still works (Casey has a great slide that shows this, so I definitely recommend looking up the talk on Confreaks when it’s up). Strong consistency means that parts of the database will remain in sync with one another. Finally, partition tolerance means that if the cable comes out of the wall, the database will remain running.

When you have a distributed system, there are a few data modeling options. You can do a document based inverted index or a term based inverted index. The document based inverted index means that you can write the information efficiently but that you’ll have an inefficient read process. The term based inverted index is the opposite. You have an efficient read but inefficient write system. So again, it comes down to really thinking about the data you have and what will be more important to your business processes.  Will you be reading a lot of data or writing a lot of data? The

He also talked about Highly Available systems (HA) of geohashes and one other type of HA system that I can’t remember. Lastly, I learned about some interesting components that are Riak-specific. Riak creates data siblings, which is also not possible in SQL but is possible in key value databases. Basically, when information is written into the system to the same key (so to the same data entry) from two different places (so two people are updating the same person’s file at the same time) the system will save both entries and connect them. In other systems, they just take the most recent timestamp as the most recent data but here, siblings are created and the two entries are both saved, become siblings and then the user is notified the next time that file is accessed being told “hey, you’ve got two entries here. Which one is correct?”

The rest of the talk went into some more detail on this information, how to locate zombies via zip code and other interesting components of the database but, for me, this is what I gleaned from the talk. For more examples, information, and the source code, you can check out zombies.samples.basho.com.

RubyConf: First session

My initial intention was to write up a post on what I learned at Ruby Conf this year and put everything in 1 big post, however, I've just finished writing up the first session and I'm already over a page, so I think it makes more sense to post as I complete write ups. Here's my first one about basically the first two hours of Ruby Conf 2013!

This past weekend I had the opportunity to attend Ruby Conf in Miami! It was fantastic. I learned a ton. Met a bunch of new people and really dove into some Ruby amazingness. I was also really excited because, while I have been to a few ruby conferences before, this one was the first where I really understood what was going on and could sit through sessions without being completely overwhelmed and feeling like I didn’t understand a majority of the session.

I was also a recipient of a RubyConf Opportunity Scholarship. This program paid for the conference registration and also connected me with a guide for the weekend. My amazing guide was Conrad Irwin who was able to answer any lingering questions I had from sessions I attended. Conrad was very helpful and really advanced the amount of learning I was able to do and amount of information I was able to process.

So, let’s begin… the day started with a keynote from Matz (Yukihiro Matsumoto). For some reason, I didn’t think Matz would actually be there but he was and it was great. His talk was more to set the tone of the conference than go into technical details but a few points he made were great. First, appreciate your garbage collectors. Garbage collection was actually talked about a handful of times over the weekend but this was the first. Second, appreciate and respect are key. I think this is one of the reasons why I love the Ruby community so much… because these ideals are held paramount and discussed throughout the conference, but especially at the beginning to set the tone. Finally, an interesting note about open source was made, that OSS is like a shark, it needs to keep moving or it will die. All great points to set the tone for the rest of the weekend.

Onto the track sessions.

The first session I attended was on “A Peek inside the Ruby Toolbox” with Loren Segal (who, by the way, is interested in mentoring a new developer who's learning to code. If you’re interested, you should tweet at him @lsegal). Loren spoke about the really good tools the Ruby community has like deployment/ops, documentation, and testing, but mostly focused on where we could improve. The talk started with Visualization. There are lots of great visualization tools out there but none for ruby. Some example given were visual studio, which is a diagnostic hub which shows CPUs, load times, etc. It also has a built in debugger. XCode was noted as a good visualization system. VisualVM which is JVM code. All of these tools really help with discoverability which was interesting to think about. Discoverability is basically being able to have a visual representation of what’s going on. The other tool mentioned was firebug which is considered a really awesome visualization tool and it is the inspect element function in FireFox. Right now, Ruby Mine is available for Ruby but it’s not awesome and fairly expensive. He also spoke about profilers like perf tools which results in a graphic diagram that runs through code and new languages like JRuby which have a JVM.

Next, he spoke about Linting… which is not picking lint out of your belly button or using a lint brush to make your clothing un-fuzzy. Linting tools are basic “check up” tools that help determine if your code is good or bad. Linting tools detect code smells and should find common errors. In Javascript, there is JShint. Currently in Ruby, a few tools exist… Reek, Flog, and Flay. The issue, however, is that these tools test the prettiness of code, not if it is good code (more on good code versus bad code in a later talk). These are some of the tools Code Climate uses to rate code there. There’s a new tool called Ruby-Lint but again, it’s new, and so Loren wasn’t sure how good it is. I’m excited to look into it more!

Next, he talked about Static Analysis. Static Analysis is bug checking/ defect finding. Here, I learned about Fuzz Testing (almost as cool of a name as linting but not quite). Fuzz testing is when you throw a bunch of crap into you application to see what breaks it. (I later learned the SQL is well known for its fuzz testing). It seems like there are lots of interesting things to look into further about fuzz testing but what currently exists are heckle, which fiddles with if statements to see If the tests fail and mutant. Finally, he also spoke about symbolic execution which runs code with no immediate values. I wasn’t able to really wrap my head around this… it’s something that has to do with math, testing values, and automatic test case generation. Right now there’s nothing in Ruby for symbolic execution.

In the category of random knowledge learned, In this talk, I also learned about what an IDE is! I hear people say it all the time, but never fully comprehended what it was exactly. Anyway, an IDE (integrated development environment) is having all the tools you need in one window so XCode is an IDE and so having an IDE would mean that instead of having a text editor, console, etc. all open, you’d have it all in one place.

Great session and lots of new stuff to look up. It will also be interesting to see what new tools are built based on these weaknesses in our toolbox.