| CARVIEW |
Popular topics:
Programming Posts
Location, Location, Location
Why where you put your script element matters
Everyone knows you add JavaScript to your page by putting your <script> element at the top of your HTML page, right? Not so fast. In part two of Head First JavaScript Programming Teasers, Eric explains the nuts and bolts of the <script> element: how to add it to your page, and where.
While you can put a <script> element just about anywhere in your code, there are a couple of things you should know before you make any decisions about where to add it. For instance, you might already know that the browser reads your page top down and starts executing your JavaScript as it gets to the code. That means if you put your JavaScript in the <head> of your document, the browser will execute the code before it loads the rest of the page. That might be what you want… or it might mean that users are sitting there looking at a blank page while your script is executing.
Watch the video for a couple of other tips about the <script> element, taken from our upcoming book, Head First JavaScript Programming.
And if you missed the first part of this video series, you can watch it here.
Drupal for Designers
Dani Nordin on what you need to know
Dani Nordin (@danigrrl) is an O’Reilly author (Drupal for Designers) and UX designer.
We sat down recently to catch up on her current projects and her predictions for the future of Drupal design. She shared some best practices for designing, her experiences with a large-scale academic project, and what criteria goes into the Design 4 Drupal Boston event.
Highlights from the conversation include:
- Learn the common pitfalls Drupal designers fall into, along with some tips and tricks to avoid them (hint: Drupal is like a cake recipe) [Discussed at the 0:17 mark].
- How the Berklee College of Music is using Drupal [Discussed at the 5:49 mark].
- The focus for 2013′s Design 4 Drupal Boston [Discussed at the 7:50 mark].
- The ways Drupal 8 could change how designers work [Discussed at the 9:40 mark].
You can view the entire interview in the following video.
Tech Events You Don’t Want to Miss
IBM Impact Unconference, Jeff Gothelf on Lean UX, MongoDB, and more.
Each Monday, we round up upcoming event highlights from the programming and space. Have an event to share? Send us a note.
IBM Impact Developer Unconference: Tim O’Reilly is speaking, Grady Brooch is speaking, and AT&T is throwing a hackathon. Visit their website for more information and to register.
Date: April 28-May 2 Location: Las Vegas, NV
Lean UX book discussion with author, Jeff Gothelf: Jeff Gothelf talks about his new book, Lean UX: Applying Lean Principles to Improve User Experience, in person and via livestream. You can even tweet your questions to @UXBCLA. For more information on attending the event in person, visit their Meetup page. Register for the free livestream at their event page.
Date: 6:30 p.m. PT, April 30 Location: Venice, CA; also an online livestream webinar
Go Native, Go Big, and Go Deep
Android software development at a crossroads
Apps have to get bigger and more ambitious. A key question for the developer community is how do you create big, integrated, multi-functional, configurable apps for the mobile enterprise? Curiously, Facebook is providing some answers by not using HTML5 and not attempting to make a cross-platform app. Go native, go big, and go deep.
Facebook Home is a harbinger of serious mobile apps
Facebook Home has earned positive reviews—in many cases from reviewers who had tired of Facebook and the intrusiveness of Facebook’s privacy policies and practices. Facebook Home is an example of a new kind of Android software development. It spans a variety of functions as a suite of cooperating software. It uses Android’s intent filters, high-level interprocess communication (IPC), shared databases (ContentProvider components) and remote APIs to bond together a software product that replaces many of the standard parts of Android—as they are meant to be replaced.
Facebook Home isn’t some kind of rogue hack, nor is it a “fork” of AOSP, as Kindle Fire is. Facebook Home is a tour de force of correct Android application architecture. It takes over your phone, interface by interface, always playing by the rules, and it does so for justifiable reasons: for putting Facebook’s functionality everywhere you want to perform communications and social media functions.
Going native
Moreover, Facebook Home simply can’t be done on iPhone. iOS has a specific vision of apps that is separate from system software, while Android’s frameworks are the basis of both applications and system software. Facebook Home was built with this difference in mind: It replaces key elements of the Android system user experience. It is a suite of communicating apps. The word “app” doesn’t sufficiently describe it.
A Human Approach to Postmortem Reviews
Dave Zwieback on how considering the human side of outages and postmortems can help build more resilient systems and teams.
There is nothing pleasant about postmortem reviews following an outage, and many companies struggle to execute positive, effective reviews. In a recent interview, Dave Zwieback (@mindweather), head of infrastructure at Knewton, said that we often focus only on technical issues during postmortems, to the exclusion of human elements. We also tend to fall into the “blame game” and point fingers when assessing particularly bad outages, he said.
In the following interview, Zwieback addresses the importance of including human and organizational elements in postmortem reviews, and outlines contributing factors to take into consideration, such as particular stressors and cognitive biases. He will address these issues further in a free online webcast, The Human Side of Postmortems, at 1 p.m., (PT) April 30.
How are postmortems typically approached, and why is it so important to make human and organizational factors more of a concern?
Yet another JavaScript book?
For the next 15 weeks, a new learning video every week.
Eric Freeman and I are writing a new book: Head First JavaScript Programming, and to go along with it, we’re creating a series of teaser videos to give you a taste of what’s coming in the book, and a chance to learn a few JavaScript tidbits.
Why undertake writing a JavaScript book now? After all, isn’t there already a Head First JavaScript book (not to mention all the many other JavaScript books on the market)? Well, to make a long story short, when we published Head First HTML5 Programming, a book that teaches you how to use all the new HTML5 APIs (with JavaScript, of course), we discovered something: a lot of folks know a little JavaScript, but really want to understand it at a deeper level. They want to go beyond just simple scripting. To remedy that, we ended up taking a month to write a brief introduction to JavaScript in our Head First HTML5 Programming book, but it wasn’t enough. Readers needed more.
Agile in name only
Agile isn't agile if you end up going over a waterfall at the end.
In politics, the term RINO is used to refer to a candidate who is “Republican in Name Only,” i.e., claiming the mantle of the party, but not conforming to the platform or belief system. In software development, there’s a similar phenomenon: companies that claim to embrace agile development principles, but really don’t understand agile. They’re Agile in Name Only (AINO).
I’ve written before about “waterfall with a crunchy agile shell,” the problem that if you are trying to control all three of the variables (time, features, resources), you can’t really do agile. Agile acknowledges the uncertainty in development estimates, and requires the team to stay “ready to ship,” so that when the decision is made to pull the trigger on a release, all the work done to date can be easily consolidated and shipped. But focusing on keeping shippable units in shippable shape only makes sense if you also embrace the idea of frequent releases, and putting only in the release what fits in the bucket.
In contrast, a company that’s agile in name only will cling to a distant release date and a laundry list of features, but still insist on short sprints and closing stories. At this point, the benefit of short sprints isn’t for the developers or the team, it’s for management, because it lets them focus on their burn-down charts, and chart the progress toward that eventual release that may be a year away.
Read more…
Twisted Python: The engine of your Internet
Learn to build event-driven client and server applications
I want to build a web server, a mail server, a BitTorrent client, a DNS server, or an IRC bot—clients and servers for a custom protocol in Python. And I want them to be cross-platform, RFC-compliant, testable, and deployable in a standardized fashion. What library should I use?
Use Twisted
Twisted is a “batteries included” networking engine for writing, testing, and deploying event-driven clients and servers in Python. It comes with off-the-shelf support for popular networking protocols like HTTP, IMAP, IRC, SMTP, POP3, IMAP, DNS, FTP, and more.
To see just how easy it is to write networking services using Twisted, let’s run and discuss a simple Twisted TCP echo server:
from twisted.internet import protocol, reactor
class Echo(protocol.Protocol):
def dataReceived(self, data):
self.transport.write(data)
class EchoFactory(protocol.Factory):
def buildProtocol(self, addr):
return Echo()
reactor.listenTCP(8000, EchoFactory())
reactor.run()
With Twisted installed, if we save this code to echoserver.py and run it with python echoserver.py, clients can now connect to the service on port 8000, send it data, and get back their echoed results. Read more…
Building native apps from JavaScript using Appcelerator Titanium
An interview with John Anderson
In this interview, the author of Appcelerator Titanium: Up and Running describes how Titanium can be used to generate native mobile apps from JavaScript code. He distinguishes the Titanium platform from native API programming and from other popular JavaScript platforms for mobile devices. We look at the way Titanium exploits the expressiveness and flexibility of JavaScript, and some of the directions that the Appcelerator company is taking Titanium.
Read more…
HTML5 makes offline web apps possible
Jonathan Stark will offer hands-on instruction in offline web app design for web designers and developers.
With advances in HTML5, web apps no longer require an Internet connection — thanks to HTML5′s support of client-side storage, web apps now can run offline in today’s browsers.
“An HTML5 offline application is simply a website that has been configured to store data locally in the user’s browser so that some or all of its functionality is available when the device is not connected to the Internet,” mobile consultant and web evangelist Jonathan Stark explained in a recent interview. “There are several technologies in the HTML5 family of specs that make offline web apps possible — Offline Application Cache, Web SQL Database, Web Storage, etc.”
Browser support, of course, is an essential consideration. “Support for the most critical offline technologies (Offline Application Cache, Web Storage, and Web SQL Database) is very good across both desktop and mobile browsers,” Stark said. “Even so, I recommend treating offline support as a progressive enhancement — if offline support is an absolute requirement for your web app, you’ll probably have to document which browser/OS combinations are explicitly supported and provide ‘best effort’ support for everything else.”
You can find out more about HTML5 and offline web apps at the upcoming O’Reilly webcast, “Building Offline Web Apps with HTML5,” presented by Stark, on Thursday at 10 a.m. PT. Attendees of the webcast should have a working knowledge of HTML and JavaScript, Stark noted, adding that “experience with SQL is helpful if you plan to use Web SQL Database.” You can sign up for the free, hour-long webcast on our O’Reilly Community site.
