TensorFlow kicked off their 3rd annual summit last week with a lot of new developments and releases. We have new updates on almost every aspect of TensorFlow.
TensorFlow kicked off their 3rd annual summit last week with a lot of new developments and releases. We have new updates on almost every aspect of TensorFlow.
The new MacBook Pro’s 6 cores and 32 GB of memory make on-device machine learning faster than ever.
Every year brings changes in tech. Here are some of the things I’m excited to learn more about in 2019.
I was exhausted after my first few months, under the impression that I would be devoting a huge amount of emotional energy to every project that I would ever manage for the unforeseeable future… When I shifted my thinking from trying to be good at everything to being excellent at a few things, I finally felt settled into my role.
How to implement a flux pattern in VueJS without Vuex. Use VueJS’s reactive framework to manage state in 38 lines of code
In this series, we have looked at what it takes to build a great Engineering Team. This post is going to be a little different as we chat with Angie Terrell to get some of her thoughts on the topics shared thus far. Angie is the director of the Design team at Big Nerd Ranch, where she is also a Design Bootcamp instructor. Angie has been leading the Design team for over three years now and continues to push Big Nerd Ranch to excellence in all of the disciplines of Design for Digital Product Development.
In this series, we have looked at what it takes to build a great Engineering Team. This post is going to be a little different as we chat with Chris Stewart to get some of his thoughts on the topics shared thus far. Chris is the director of the Android team at Big Nerd Ranch, where he is also an Android Bootcamp instructor. Chris co-authored the best selling Big Nerd Ranch guide on Android Programming and has been leading the Android Engineering team for over five years.
Part of building something great is building it to last. No one builds a home for a season, and the same is true for your Engineering team. Retaining your team for the long haul is no easy task, but it is imperative that as a leader it is a priority. Let’s take a look at a few things you can do to retain your excellent Engineering team.
Are you hiring with character in mind? Are you too focused on skill and find yourself overlooking traits that clash with your values? Knowing where you are on these fronts will go a long way in helping you build a great team.
When you inherit a team you inherit not only the people but you also get the culture and any baggage that comes along with that. It is imperative as leaders inheriting a team that we assess where we are so we can know where we need to go.
Because a great team is composed of a diverse group of individuals who are all leading themselves well. If you want to see any behavior in your team you have to first see it in yourself. Be what you want to see.
Students have more options than ever, and it can be overwhelming to choose the right program. Bootcamps vary drastically in cost, time commitment, and career-growth options, and the decision can be daunting for many prospective students. Here are 4 tips to help.
Have you ever wondered what goes into a mobile app that you use on your smartphone? Wonder no more! There’s no magic to the apps we use. While we won’t dive into nitty-gritty details of a mobile app’s architecture, this easy-to-understand diagram should give you a good foundation to communicate your needs with us.
One thing that sets Big Nerd Ranch instructors apart is we consider ourselves students first. That’s definitely the case with Kristin Marsicano, whose passion for learning and asking questions has solidified her as an Android expert in a few short years. Her advice to all her fellow programmers out there might surprise you.
Big Nerd Ranch esteems code review. We’ve seen it pay off time and again. It is core to our workflow and process. If you want to experience the benefits in your team, here’s what that means in practice for everyone involved.
WWDC 2017’s Design for Everyone challenges developers to work for all our users. This post will teach you to rise to the challenge through concrete examples of accessible design. The examples I list are iOS-specific, but the ideas aren’t—developers across all platforms should keep accessibility in mind.
Making your apps accessibile is hard work, especially when dealing with Accessibility Traits. Discover a straightforward way of handling it, and then another more creative solution to make it more Swifty.
Technology should be accessible to everyone. Apple has worked hard to make it easier to support Accessibility. Here’s some tips on how to support it.
In the previous two posts on Ember Engines, we started building an Ember “umbrella” application for mounting a couple Ember Engines. In this post, you will share links and services, like store and session, between the parent app and the engines.
In this post, you will learn to create an Ember Engine in a separate repository and link the engine to the umbrella application.
Finding time to level up your skills can be hard, but finding the money can be an even bigger roadblock. Here are some of our best tips for paying for your coding bootcamp.
In the last few years, PHP has experienced a bit of a renaissance; the language got some significant upgrades and the community has adopted some new software engineering practices. Discover how the PHP ecosystem has changed in recent years.
“Where were you born?” and “What is your mother’s maiden name?” are common security questions, but if you answered honestly, someone can probably get into your account in just a few minutes of half-hearted Facebookery. Password generator to the rescue!
Taking the time to learn a programming language is a huge accomplishment, particularly for those people who are looking to find full-time work as a developer. However, successfully learning one language does not mean that the work is done.
Usually when I hear a conversation about Dependency Inversion, one of the SOLID principles of object-oriented design, a question comes up about its name. It’s often summarized as “depend on abstractions,” and that makes sense, but why is it called dependency inversion? This isn’t just a matter of trivia; understanding the “inversion” in dependency inversion has the potential to transform your abstractions from pointless formalities to powerful design tools.
Phillip interned with Big Nerd Ranch as a backend developer in 2015 and was hired as a permanent employee after the internship. In this interview, he describes his journey from non-developer to Nerd.
It can be difficult to work up the courage to dig into machine learning. Luckily, many of the ideas are actually quite straightforward when you peel back the terminology.
In all areas of the app development world, designers and developers run into the issue of not being able to communicate efficiently. At Big Nerd Ranch, we’ve encountered this problem before, but have improved our communication over the years. Recently, my colleague Kristin Marsicano and I sought to identify what designers and developers at Big Nerd Ranch have done to improve our ability to communicate effectively with one another.
Every build pipeline is an opportunity for leaks and stoppages. Understanding how all the bits come together to make a functioning app helps you to plumb your way through these problems. So… How exactly does Swift and Obj-C all turn into one app?
Is it possible to ask a question that leads you directly to fixing a bug? If so, how do you find those questions to ask them?
When you’re trying to get into testing, often you may hear the advice ‘don’t test the framework’. This made sense to me at first, but over time I started to see situations where this universal statement doesn’t quite apply. Here are a few situations where a kind of ‘testing the framework’ may be the right thing to do.
Maybe you’re convinced of the value of breaking large chunks of code into smaller pieces, but are you familiar with the different ways it can be done? Each of these decompositions has its own pros and cons, and learning about them will help you choose the best approach for your situation.
It’s my third year working at Big Nerd Ranch as a developer and instructor. Inevitably, I have a lot of friends (and recruiters) asking me why I am still working here. It all boils down to two non-negotiable values—trust and kindness.
Automated testing is the software equivalent of eating your vegetables. You could, you should, but… eh, maybe next time. But then “next time” never comes around. Finding the perfect time to take that first step into testing seems a challenge best avoided, especially when you don’t really know what awaits.
Good news! I’ve found the perfect “next time,” and you’re probably going to have a few opportunities to level up your testing skills today.
We love to teach here at Big Nerd Ranch, but we don’t just teach classes. We write blog posts and speak at conferences, too. For all of these activities, we inevitably have code we want to share. Sometimes the best way for us to do that is via a demo app.
Comments have been the target of much negative advice—delete them! rewrite to eliminate them!—but little positive advice. Let’s take a look at why they get a bad rap, then examine why the right kind of comments are indispensable.
A few weeks ago, I had the pleasure of helping to teach the Big Nerd Ranch Ruby on the Server course with fellow Nerd Zac Stewart. This opportunity has been a year in the making, and it didn’t disappoint.
…and upon looking into the face of indescribable horror, a bug so unfathomably odd that it shook the foundations of all meager human beings, I was overcome by an indistinct feeling of dread and approximate horror previously unfamiliar to me.
You can find Part 1 of this series here.
Like most people over 40, I have lots of opinions about how people should live their lives. Recognizing that no one wants this unsolicited advice, I work hard to keep these opinions to myself. However, today Tasha (who curates our blog) asked me to write some advice to the young people who are graduating this spring. Thus, I’m about to blurt out some advice that I sincerely hope will be useful to you; I apologize in advance for being a preachy loud-mouth.
You can find Part 2 of this series here.
Every day I used to ask myself, “Does someone artistic like me have what it takes to become a software engineer?” These days, I wonder why I even had to ask.
When I started at Big Nerd Ranch, I was starved for code review. I had received very few deep, insightful comments on the code I had produced up to that point. Then the code review process at Big Nerd Ranch changed the game for me.
The Universe is a big place. For someone who’s keen on learning new things and absorbing information, that is both a blessing and a curse. On the one hand, it’s great because it means there are many different things you could learn next. But then you encounter choice paralysis: with so many options, which one should you choose?
I’ve been here for a couple of months now, but before I came to Big Nerd Ranch, I gave some consideration to the things that I was looking for in a new employer. I thought about past jobs and things I’d seen at other “cool” companies like Google or Facebook, and even dreamed up a few things of my own.
The Instruments Time Profiler is a common tool to use when finding out how much CPU time is being consumed for an operation, either directly by a function or a method, or on behalf of some other piece of code. You might discover that your image drawing is causing huge amounts of image conversion inside of Quartz. You’d then make sure your image is in a state that makes it draw faster.
As programmers, we revel in the details. We’ll pour our time and money into growing our craft for the sheer joy of it. That’s why we’re incredible. We discover the pricelessness of version control systems and services early in our careers. Tools like Git give us the feeling of invincibility!
In my internship at Big Nerd Ranch, I learned not only new ways to solve problems, but new ways to think. As I’ve written before, I have valued the emphasis on empathy, thoughtfulness and learning. The sun has now set on my internship at Big Nerd Ranch, but I’ll continue to be a self-admitted fanboy for another reason.
How many interns do you know with a Ph.D.? This summer, I may have become the first.
We’ve taught our iOS Mobile Design and Android Mobile Design bootcamps all over the world this year, and one question that we’ve continually heard is, “How can designers and developers collaborate effectively?” There’s a gap between designers and developers who create mobile apps together, and while I don’t have a simple solution, I do have some thoughts on closing that gap (or at least bridging it).
Editor’s note: Each spring, Big Nerd Ranch hosts an epic 72-hour app-building competition, suitably named Clash of the Coders. We sharpen our technical skills and vie for the Clash trophy to earn ultimate bragging rights. This year the competition kicks off at the end of day on Wednesday, May 1, and runs through Saturday, May 4.
If anyone would have told me 30 years ago that I’d actually enjoy writing, that I’d look forward to writing something new, that I’d earn part of my living from the act of writing, I would have sent them straight to a psychiatrist. Obviously they’re insane.
Building small prototypes outside of your main code base can let you experiment with new technology and APIs. An interesting question is, where does that code live? In your $HOME? In a “Projects” github or bitbucket repository? Or maybe they should live next to the project the work was done for.
A couple of weeks ago I extolled the virtues of public speaking for tech nerds. Now it’s time to ruminate a bit on actually creating a conference session.
I’m becoming a conference junkie.
Source code control. What is it? Why would you want to use it?
Executive summary: If you’re not using source code control, you need to be.
I’ve been lucky enough to have gotten to tech review a number of Mac and iOS programming books. I find the process very enjoyable, if a bit time-consuming. I assume I do a decent job because publishers and authors come back to ask me to review subsequent editions of books, or entirely new books.
Brandon Beacher talks about software craftsmanship and how diligence ensures a quality product.
I usually encounter two classes of bugs on a regular basis. The first is of the form “I think I know where this is” which won’t take long to find. The steps are pretty easy: Figure out how to reproduce it. Set a couple of breakpoints. Add some caveman debugging. Find the problem and fix it. These are my favorite kind of bugs because they’re over and done with quickly, I can get a quick hit of that “you done did good” glow from making a software system better, and then move on to some more interesting problem.
Ever have one of those moments, after a flurry of activity, and realized what you’ve accomplished? Now that this summer is over, I realized that I’ve talked a lot. Three CocoaHeads presentations. Back-to-back 90 minute sessions at two CocoaConfs. Taught a week-long class with some extra evening sessions. Granted, that’s not a lot considering some folks who teach week-long classes a couple of times a month, or professional speakers out on a circuit, but for Just Some Dude who’d rather be writing software, it’s a lot.
You know that feeling. You’re on a deadline. It’s 9:00 at night. You have a demo the next morning. Suddenly Xcode freaks out. Apps running half the time. Rebooting your phone. Rebooting your computer. Finally the phone decides to run your App for awhile.
Highgroove really likes Pry. It’s a great tool for digging into your code and seeing what’s going on with tons of great features. However, there are situations where using a standard
binding.pry breakpoint will not block your program and allow you to inspect it. I recently ran into this situation when trying to debug an application that used Foreman to manage it’s processes. Luckily, the pry-remote project turned out to be a great solution.
As a developer, I always try to follow the “Boy Scout Principle” when it comes to the code I’m working with. Simply put:
At rubyhoedown, the inimitable Jim Weirich gave an awesome presentation on using the debugger in ruby. Before his new found respect for the ruby debugger, Jim told us that puts statements worked just fine for him.
Every programmer has had this thought: “Just 15 more minutes and I’ll have that feature working!” And 15 minutes come and go, and before you know it its been an hour and the feature still isn’t working ideally. In fact, you’ve skipped lunch and have accomplished far less than you had hoped.
It’s a good thing we don’t charge by the lines of code we write in an application.
New albums drop on Tuesdays, why not drop some nifty knowledge as well?
Most developers think that every “other” developer’s code is “no good.” In fact, it is exactly this “Not Invented Here” syndrome that makes it dangerous for other developers to evaluate an existing project’s quality without a checklist or template as a guide.
One of my coworkers, Scott, recently pointed me towards Jacob Kaplan-Moss’s comments on programming languages and thought. In “Syntactic Sugar”, Jacob addresses the canard that “all Turing complete language differ solely on syntactic sugar.” He first concedes that this is technically true, in terms of reduction to machine instructions and register manipulation. At the same time, he says, this view ignores the important effect qualitative differences in the syntactic structure of different programming languages have on the way we as programmers solve problems. In support of this, he introduces the Sapir-Whorf hypothesis from linguistics, which states that, rather than simply being a vehicle for thought, language in fact determines the limits of what is thinkable. He argues that this applies equally to programming languages, and concludes that “we’ll always be more productive in a language that promotes a type of thought with which we’re already familiar.”
One of the most important (and least loved) activities in a programmer's life is debugging code. When debugging PHP, there are several strategies, ranging from strategic use of print_r to elaborate systems that send debugging information to specific debug tables in a database.
In this article, we look at a simple tip for finding errors in SQL code when using PEAR::DB.
This article, originally published in MacTech Magazine, gives tips on how to write your code such that retain count problems are easier to find and how to locate the problem when symptoms appear.