Brains Are Like Muscles, and Tackling Complex Skills Like Web Development May Help Strengthen Them

Learning how to program for the first time was a challenge for Adam Waxman.

He worked as a full-time investment banking analyst in Atlanta, but in January 2013, his nights were less about reclining after a day’s work and more about teaching himself Objective-C and JavaScript with books and online tutorials.

By that summer, he left his career in finance behind and moved to New York to enroll in a programming boot camp where he learned Ruby on Rails.

“It’s like learning a foreign language,” says Waxman, 25, a product developer at SeatGeek, a New York ticketing start-up. “It’s much easier to learn a programming language by being very immersive.”

Careers in code and programming are no doubt booming. But are there less-visible benefits? Can a career in software and web development keep you healthy and fit, particularly your brain? Besides agile software development methods, meet-up groups and collaborative projects — which help foster social interactions — programming involves creativity, critical thinking and algorithmic skills necessary to complete tasks.

“When people say they want to learn to program, what they’re really saying is, ‘I want to solve a problem that the computer can help you with,’ ” says Sherif Abushadi, an educator at Dev Bootcamp, who has nearly 13 years of experience teaching development. “In fact, most programmers spend half their time failing over and over and fixing those mistakes until they get it right.”

Early Studies on Brains and Computer Programming

That analytical approach in the context of brain development and computers has been explored for decades.

In 1980, MIT mathematician Seymour Papert, a co-founder of the programming language LOGO, published the pioneering book “Mindstorms: Children, Computers and Powerful Ideas.” Papert claimed programming provided children with new opportunities for learning and thinking. A series of studies on the cognitive effects of programming determined that Papert’s claims were problematic, but other research studies like the “Effects of Computer Programming on Cognitive Outcomes,” and those conducted at institutions like MIT, have shown that programming can be beneficial to cognitive development.

Free trial on Treehouse: Do you want to sharpen your web design and development skills? Click here to try a free 14-day trial on Treehouse.

Ongoing empirical studies will be important, of course, but here’s what we know generally about the brain: It’s like a muscle, which means we need to exercise it to conserve brain vitality, according to many research studies cited by the National Institutes of Health.

For some programmers, the ability to simplify complex issues is similar to a brain workout.

“I don’t think it’s something that’s magical, where all of the sudden I feel much smarter, but I do think that programming in general is all about tackling pretty large, unknown problems and breaking it down into smarter pieces that makes sense, ” Waxman says.

Errol King, 29, the director of experience for the kids programming app Beta, says the logical thinking skills he has acquired are transferable outside of the tech world: “The more I go into code, the more I see the world from that perspective.”

It’s not too Late to Train Your Brain

According to research, brain exercises help improve brain function and can possibly fight dementia. But as for brain games — well, science hasn’t exactly jumped on the bandwagon. Still, living a cognitively active lifestyle is never a bad thing — especially when we give our minds and bodies time to relax, says Dr. Sherrie All, a neuropsychologist and founder of the Chicago Center for Cognitive Wellness.

“We grow new brain cells throughout our entire lives and not at a very high rate so you want to keep the ones you have,” she adds.

One way to keep the brain young is learning a new skill. Last year, researchers from the University of Texas at Dallas discovered that mentally challenging activities that you’ve never done before can sharpen the brain.

When we learn a new programming skill — such as Python, PHP, Ruby on Rails, or other complex activities outside of programming like digital photography and juggling — our brains are forming new neural connections while strengthening existing ones each time we practice, according to the National Institutes of Health.

This illustration is from “The Home and School Reference Work, Volume I” by The Home and School Education Society, H. M. Dixon, President and Managing Editor. The book was published in 1917 by The Home and School Education Society. This illustration of the parts of the brain can be found on page 368. The parts are A. Cerebrum; B. Corpus Callosum; C: Medulla Oblongata; D. Arbor-Vitae; E: Cerebellum, F: Pons Varolii (Illustration from Flickr user Sue Clark)

Of course, there will always be tasks we can perform faster when we’re younger, but that doesn’t mean we’re incapable of doing them when we’re older, either. Moreover, professionals in their 40s and 50s are stepping outside of their comfort zones to explore careers in code and programming, which supersedes the misconception that our brains are inflexible.

“As people get older, they actually don’t lose the capacity to learn,” All says. “Our brains are constantly changing up until the point that we die.”She adds:“I’ve learned [to code] before and it’s a really complex brain exercise.”

New York-based actress Ondina Frate, 31, a beginner enrolled in CS50X, an introductory online programming class at Harvard, looks forward to the challenges of the training.

“It’s not as tough in the first week, but then it’s starts [getting] harder,” she says. “It’s very precise and detailed. You have you be very analytical.”

There are no shortages of Meetup groups or tech organizations, including New York Entrepreneurs & Startup Network, Just Dev It and Silicon Valley NewTech, all of which offer support and networking opportunities to programmers, developers, and coders.

“It’s also very comforting to know that there are other beginners, too, and if you don’t know something, you can talk about it,” Frate says.

Researchers from the Rush University Medical Center and University of Michigan found that similar social connections are advantageous for brain health. Like other social environments, exchanges in tech communities are exercises for the brain because of social and language skills essential to having a conversation.

“I think that when a lot of people think of programmers,” Waxman says. “They think of a nerdy guy or women alone that’s probably trying to do something all by themselves when the beauty of code is that you’re making something [together] that can help a lot of people in everyday life.”

The post Can Computer Programming Boost Your Brain Power? appeared first on Treehouse Blog.

Two years ago, we started building a product that would help teach people the skills they needed to succeed in a digital world. As more than 24 million people took Codecademy courses on our web and iOS platforms, we too learned and grew. Now, we’re excited to show you our latest project — a new Codecademy designed from the ground up, aimed to help you learn skills hands-on, with real projects, and constant feedback. Better yet, the new Codecademy experience helps to connect you with the real skills you’ll need to succeed in today’s workplace.

Learning isn’t just about one exercise or “class,” but instead is a gateway to community, opportunities, ideas, and a better life. We’ve witnessed this through the millions of learners on Codecademy and through the thousands of inspiring teachers who have shared their knowledge with the world with our course creator. We listened to them while building what we think is the best learning experience — for anyone, anywhere — to learn the most important skills of today.

In two years, Codecademy has scaled to become larger than we had ever imagined. Our learners, spread across the globe in every country in the world, have:

• written more than a billion lines of code
• joined more than 24 million others in starting the journey of learning to code
• helped to create more than 100,000 courses using our course creator
• hosted meetups in more than 350 cities
• learned on-the-go through our mobile apps for iPhone and iPad, both of which have been featured in the App Store
• worked with nearly 100 partner organizations like The White House and Twitter to both learn and spread their knowledge even further

Today, we’re proud to show off the results of all of that to a few friends and, within days, the rest of the world. The first fruits of this effort are an experience that gets you from knowing nothing to building a website — in this case, Airbnb’s homepage. Along the way, you’ll experiment with blocks of code, see the results of adding and subtracting different parts of a page, and use the real terminology that developers and designers all over the world over use to create websites just like Airbnb’s.

Our new platform leaves you not just with new knowledge, but with a portfolio of projects you can share with your friends, enabling them to learn from you. We’ve even built the capability for you to share your work with future employers, and to demonstrate your new skills. We’ve been testing our new learning interface for weeks and we’ve seen it applied in an amazing number of ways — from designers at major firms winning new consulting work because of their ability to build their designs to students in high school making personal webpages for themselves.

Codecademy’s learning experience comes not just from the data behind 24 million learners and billions of lines of code, but also from the individual stories we’ve heard from our wealth of committed learners. Former book critic Juliet Waters, for instance, started learning with her 11-year old son as part of our Code Year program in 2012. Since then, she’s gone on to chronicle her journey in a book that’s coming soon, noting that programming helped her feel “more connected with others in our tech-driven society.” A parent named Shari told us that her 11 and 13-year old sons had a “reaction to what they are learning [that] beats their enthusiasm for the [video games].” We work hard everyday to deliver a similar experience for our users all around the world — with more than 65% of users outside the US, it’s important to us that we’re democratizing access to the fundamental blocks of knowledge that can improve peoples’ lives.

Tommy Nicholas’ story is just the sort we’re hoping our new learning environment will foster: he began with almost no programming knowledge at all, and gained enough skills to develop a website, Coffitivity, that was named one of TIME Magazine’s Top 50 websites in 2013.

Billions of lines of code, millions of users, and years after our founding, we’ve been astonished by what people can do when they can easily learn the fundamental skills that can transform their lives. Today, we’ve redesigned Codecademy to reflect that potential — and hopefully to help more people reach their goals and build the future they want to live in.

If you want to help us, we're hiring!

Phil Karlton once said, “There are only two hard things in Computer Science: cache invalidation and naming things.” This article is about the harder of these two: cache invalidation. It’s directed at readers who already work with Varnish Cache. To learn more about it, you’ll find background information in “Speed Up Your Mobile Website With Varnish.”

10 microseconds (or 250 milliseconds): That’s the difference between delivering a cache hit and delivering a cache miss. How often you get the latter will depend on the efficiency of the cache — this is known as the “hit rate.” A cache miss depends on two factors: the volume of traffic and the average time to live (TTL), which is a number indicating how long the cache is allowed to keep an object. As system administrators and developers, we can’t do much about the traffic, but we can influence the TTL.

However, to have a high TTL, we need to be able to invalidate objects from the cache so that we avoid serving stale content. With Varnish Cache, there are myriad ways to do this. We’ll explore the most common ways and how to deploy them.

Varnish does a whole lot of other stuff as well, but its caching services are most popular. Caches speed up Web services by serving cached static content. When Varnish Cache is delivering a cache hit, it usually just dumps a chunk of memory into a socket. Varnish Cache is so fast that, on modern hardware, we actually measure response time in microseconds!

Caching isn’t always as simple as we think; a few gotchas and problems may take quite some of our time to master. (Image credits)

When using a cache, you need to know when to evict content from the cache. If you have no way to evict content, then you would rely on the cache to time-out the object after a predetermined amount of time. This is one method, but hardly the most optimal solution. The best way would be to let Varnish Cache keep the object in memory forever (mostly) and then tell the object when to refresh. Let’s go into detail on how to achieve this.

HTTP Purging

HTTP Purging is the most straightforward of these methods. Instead of sending a GET /url to Varnish, you would send PURGE /url. Varnish would then discard that object from the cache. Add an access control list to Varnish so that not just anyone can purge objects from your cache; other than that, though, you’re home free.

acl purge {
    	"localhost";
    	"192.168.55.0"/24;
    }
    
    sub vcl_recv {
    	# allow PURGE from localhost and 192.168.55...
    
    	if (req.request == "PURGE") {
    		if (!client.ip ~ purge) {
    			error 405 "Not allowed.";
    		}
    		return (lookup);
    	}
    }
    
    sub vcl_hit {
    	if (req.request == "PURGE") {
    		purge;
    		error 200 "Purged.";
    	}
    }
    
    sub vcl_miss {
    	if (req.request == "PURGE") {
    		purge;
    		error 200 "Purged.";
    	}
    }
    

Shortcomings of Purging

HTTP purging falls short when a piece of content has a complex relationship to the URLs it appears on. A news article, for instance, might show up on a number of URLs. The article might have a desktop view and a mobile view, and it might show up on a section page and on the front page. Therefore, you would have to either get the content management system to keep track of all of these manifestations or let Varnish do it for you. To let Varnish do it, you would use bans, which we’ll get into now.

Bans

A ban is a feature specific to Varnish and one that is frequently misunderstood. It enables you to ban Varnish from serving certain content in memory, forcing Varnish to fetch new versions of these pages.

An interesting aspect is how you specify which pages to ban. Varnish has a language that provides quite a bit of flexibility. You could tell Varnish to ban by giving the ban command in the command-line interface, typically connecting to it with varnishadm. You could also do it through the Varnish configuration language (VCL), which provides a simple way to implement HTTP-based banning.

Let’s start with an example. Suppose we need to purge our website of all images.

> ban obj.http.content-type ~ “^image/”
    

The result of this is that, for all objects in memory, the HTTP response header Content-Type would match the regular expression ^image/, which would invalidate immediately.

Here’s what happens in Varnish. First, the ban command puts the ban on the “ban list.” When this command is on the ban list, every cache hit that serves an object older than the ban itself will start to look at the ban list and compare the object to the bans on the list. If the object matches, then Varnish kills it and fetches a newer one. If the object doesn’t match, then Varnish will make a note of it so that it does not check again.

Let’s build on our example. Now, we’ll only ban images that are placed somewhere in the /feature URL. Note the logical “and” operator, &&.

> ban obj.http.content-type ~ “^image/” && req.url ~ “^/feature”
    

You’ll notice that it says obj.http.content-type and req.url. In the first part of the ban, we refer to an attribute of an object stored in Varnish. In the latter, we refer to a part of a request for an object. This might be a bit unconventional, but you can actually use attributes on the request to invalidate objects in cache. Now, req.url isn’t normally stored in the object, so referring to the request is the only thing we can do here. You could use this to do crazy things, like ban everything being requested by a particular client’s IP address, or ban everything being requested by the Chromium browser. As these requests hit Varnish, objects are invalidated and refreshed from the originating server.

Issuing bans that depend on the request opens up some interesting possibilities. However, there is one downside to the process: A very long list of bans could slow down content delivery.

There is a worker thread assigned to the task of shortening the list of bans, “the ban lurker”. The ban lurker tries to match a ban against applicable objects. When a ban has been matched against all objects older than itself, it is discarded.

As the ban lurker iterates through the bans, it doesn’t have an HTTP request that it is trying to serve. So, any bans that rely on data from the request cannot be tested by the ban lurker. To keep ban performance up, then, we would recommend not using request data in the bans. If you need to ban something that is typically in the request, like the URL, you can copy the data from the request to the object in vcl_fetch, like this:

set beresp.http.x-url = req.url;
    

Now, you’ll be able to use bans on obj.http.x-url. Remember that the beresp objects turn into obj as it gets stored in cache.

Tagging Content For Bans

Bans are often a lot more effective when you give Varnish a bit of help. If the object has an X-Article-id header, then you don’t need to know all of the URLs that the object is presented as.

For pages that depend on several objects, you could have the content management system add an X-depends-on header. Here, you’d list the objects that should trigger an update of the current document. To take our news website again, you might use this to list all articles mentioned on the front page:

X-depends-on: 3483 4376 32095 28372
    

Naturally, then, if one of the articles changes, you would issue a ban, like this:

ban obj.http.x-depends-on ~ “\D4376\D”
    

This is potentially very powerful. Imagine making the database issue these invalidation requests through triggers, thus eliminating the need to change the middleware layer. Neat, eh?

Graceful Cache Invalidations

Imagine purging something from Varnish and then the origin server that was supposed to replace the content suddenly crashes. You’ve just thrown away your only workable copy of the content. What have you done?! Turns out that quite a few content management systems crash on a regular basis.

Ideally, we would want to put the object in a third state — to invalidate it on the condition that we’re able to get some new content. This third state exists in Varnish: It is called “grace,” and it is used with TTL-based invalidations. After an object expires, it is kept in memory in case the back-end server crashes. If Varnish can’t talk to the back end, then it checks to see whether any graced objects match, and it serves those instead.

One Varnish module (or VMOD), named softpurge, allows you to invalidate an object by putting it into the grace state. Using it is simple. Just replace the PURGE VCL with the VCL that uses the softpurge VMOD.

import softpurge;
    sub vcl_hit {
    	if (req.method == "PURGE") {
    		softpurge.softpurge();
    		error 200 “Successful softpurge”;
    	}
    }
    
    sub vcl_miss {
    	if (req.method == "PURGE) {
    		softpurge.softpurge();
    		error 200 "Successful softpurge";
    	}
    }
    

Distributing Cache Invalidations Events

All of the methods listed above describe the process of invalidating content on a single cache server. Most serious configurations would have more than one Varnish server. If you have two, which should give enough oomph for most websites, then you would want to issue one invalidation event for each server. However, if you have 20 or 30 Varnish servers, then you really wouldn’t want to bog down the application by having it loop through a huge list of servers.

Instead, you would want a single API end point to which you can send your purges, having it distribute the invalidation event to all of your Varnish servers. For reference, here is a very simple invalidation service written in shell script. It will listen on port 2000 and invalidate URLs to three different servers (alfa, beta and gamma) using cURL.

nc -l 2000 | while true
    	do read url
    	for srv in “alfa” “beta” “gamma”
    		do curl -m 2 -x $srv -X PURGE $url
    	done
    done
    

It might not be suitable for production because the error handling leaves something to be desired!

Cache invalidation is almost as important as caching. Therefore, having a sound strategy for invalidating the content is crucial to maintaining high performance and having a high cache-hit ratio. If you maintain a high hit rate, then you’ll need fewer servers and will have happier users and probably less downtime. With this, you’re hopefully more comfortable using tools like these to get stale content out of your cache.

(al, ml, il)

The post Cache Invalidation Strategies With Varnish Cache appeared first on Smashing Magazine.