Everyone has their own opinion about this, but I found this post to be useful.
Contents
-
Categories
-
Tags
-
Archives
Blogroll
-
RSS Feeds
-
Meta
I’ve been reading the new edition of Flanagan’s “Javascript: The Definitive Guide”, straight through, and I thought I’d make some posts about what I’d learned.
In javascript, variables are implicitly declared at the beginning of the function where they are used. So, in the following block,
global = 'global'; function f() { console.log(global); var global = "local"; console.log(global); } f();
The first console.log will log ‘undefined’ instead of ‘global’ even though the local variable named global has not been defined, because the javascript intepreter knows that a local variable named global will be defined within the scope of function f and implicitly declares it at the top of that scope. Good programming practice as I had understood it is that you should declare variables as close to where they are used as possible, to narrow their scope as much as possible. With this realization, for javascript, variables should be declared at the top of their scope, to make the readable code match the scoping that the language is doing behind the scenes.
A few notes on the git things I dealt with today:
I updated my .gitconfig file to exclude everything in my wordpress directory from source control except plugins and themes. Since these were already in my repository, I need to remove them-git rm -rf –cached $files will do the trick. Note that if you leave off the –cached parameter, the files will be removed from the filesystem in addition to the repository. Care is required.
I had an upgrade to the headspace2 plugin on my wordpress installation today. When I tried to commit these changes to the repository, I got the following error:
“fatal: LF would be replaced by CRLF in blog/wp-content/plugins/headspace2/2.3/jquery.js”
I changed my core.autocrlf from input to false and re-added; this stopped end-of-line coercing and allowed me to get the file into version control. I’ve read that core.autocrlf should be on input for almost all use cases, so I’ve changed it back. I’m not sure what the long-term repository ramifications of this bit of hackery are; the headspace plugin will be a decent test case, and I’ll keep an eye out for problems.
Over the last month, I’ve been thinking a lot about how to improve kevinpaulconnor.com, but I haven’t thought very much about what that means. Today that changed; I sat down and created a mission statement and some deliverables for myself with regard to improving kevinpaulconnor.com. I’ve recently made some decisions about basic tools to fill some holes in my expertise: version control system, text editor. I’ve decided how I want my development environment workflow to fit together. Now it’s time to decide how to apply those tools.
Mission: Kevinpaulconnor.com should highlight my vision and project my professionalism as a midlevel web developer to site visitors, in terms of both Design and Content and Markup and Code.
Going over (or through!) all of the usual hurdles when you’re setting up something new for the first time. All sorts of little things to figure out, which you don’t even know need figuring out until you get there, adds up to everything taking longer than you think. I sat down this morning thinking that I’d get to start looking at all my old, crappy kpc.com markup and code finally. But instead,
-By default, xampp wants the document root of your website to be in the xampp/htdocs directory. That’s lame; I don’t want to modify my whole local filesystem structure just to please xampp. I changed the document root to the place where I was already storing kpc.com site files in the xampp httpd.conf (make sure that you change both the document root and the default directory). The ideal way to do this would be to instead set up the directory as a virtual host, so that I more easily manage multiple websites, but I’m not planning on managing any other websites besides kpc.com on this xampp installation in the near future, and it’s one less configuration change to muddle through in the present.
-When you change the document root, xampp will throw 403 errors unless you give world execute permissions, not only the specified web root and site files, but to every folder above the web root in your filesystem. It took a bit of time to figure out why this was happening.
-By default, xampp will serve .php files as plain text. To change, add “AddType application/x-httpd-php .php” to the
-It’s been on my to-do list to make a definitive decision on a terminal text editor for years. I’ve been using nano, because…I always have? That’s not a very good reason. I decided to go with vim today: I want my fingers on the home rows as much as possible, I like the concept of vi’s distinct editing modes against emac’s chords, vim adds some nice features including syntax highlighting, it’s going to be installed on anything I ever use, it’s super lightweight, and I don’t care about emacs’ GUI advantage-if I want a GUI, I’ll just kick up Text Wrangler. Pico is appealing, but marginally less universally available and significantly less beloved. A great way to get started is typing ‘vimtutorial’ into your shell and work through those exercises. It won’t give you the power user commands that make things really speedy, but it will get you enough along the way to enable you to use it. after that, :help vimrc-intro and :help user-manual, from within vim, are recommended-these are on the to-do list for next time. I’m also looking for a good vim keychart that I can print until the keystrokes get ingrained-recommendations welcome!
-I started working on a .gitignore file. I won’t want to, for example, track WordPress package changes in my git repository. I haven’t made too much progress in thinking about this…today was mostly a server configuration and editor day. An investment in future productivity!
We use Perforce at work, and that’s my only serious version control experience. Some thoughts about getting started with Git in the context of my at-work workflow:
-Both Git and Perforce have a staging step, but Perforce’s step happens prior to file edits, while Git’s is after file edits. This results in a time-wasting checkout of any file that I ‘might’ want to edit: since I can’t make any edits until I go through a checkout step, I usually might as well do it if I think I might have to edit a file. So if I’m trying to resolve an issue and I’m not sure where it is, I wind up having a bunch of unedited files checked out when I’m finished, that I then have to go through and check back in, purposelessly-or I wind up opening a bunch of files but not checking them out, and then having to go back and check them out in a separate step when I know that I need to edit them. Git’s philosophy is, keep source control out of the way until you need to deal with it. Perforce is in my face from the very beginning.
-Git is centrally concerned with changes to files; Perforce is centrally concerned with files. This is surely a change that will have wide-ranging impact on the way that I conceive of my projects. I’m just getting started, though, and since I barely have any real work in a Git repository yet, it’s hard to say exactly what those changes will come to. It’s something that I’m going to keep in mind as I continue working.
-git commit –amend allows you to add changes to an already submitted changelist, rather than submit a new one. An example of how this would be useful at work: our css/js is usually served as static assets from our cdn; so you have to remember to make changes to the separate files that bust caching so that your css/js changes are picked up. It’s easy to forget to do this; then you get two changelists, one with your actual changes, and one with the static asset cache-busting, that you have to relate to the original list via a comment. This is somewhere between pretty lame and very lame depending on my mood; with git, it would be a non-issue.
-Branching for us with Perforce involves much handwringing: managing branches is difficult for us and it’s not something we do lightly. With Git, branching is trivial. Precisely what impact that has on workflows (besides “a big impact”), isn’t clear to me quite yet, but it’s something that I’ll be keeping an eye on.
I worked through Edgecase’s Git Immersion lab, and it’s been the most useful resource for me so far. I think that I learn best while my fingers are doing something as I hear about what it is that they’re doing. I think a lot of people learn best that way, and that’s what you get to do with that tutorial.
I found that link through Git Ready, which has the best collection of Git resources that I’ve found so far. The other one that I’ve worked most of the way through from that site is Pro Git; it’s pretty good, but aimed a little shallowly for what I needed. I’ll be working through a lot of the other links on Git Ready and I’ll have more to say about them as I go. The other noteworthy resource, for specifically getting started on managing kevinpaulconnor.com development with Git, is Abhijit Menon-Sen’s guide. I think that one is a good jumping off point for how to set up your Git hooks. This is not a use case where Git is supposed to excel (a website managed exclusively by one person), so I’ll try to pay attention to places where things seem a little sticker than would be ideal.
Kevinpaulconnor.com is approaching three years old. I’ve learned a lot about development since I created the site; it’s time for a design and development freshening, with the twin goals of making the site more visually appealing while also making the code more clear and maintainable. Before that makes sense, however, my development process for the site must be improved and modernized. Currently, the development process for the files is to FTP into my hosted server and edit live files. This process has a few serious drawbacks:
-FTP is an insecure protocol-my username and password are sent in the clear across the network, meaning that anyone can gain access to kevinpaulconnor.com if they are sniffing with the right tools in the right places.
-If (when) I make a mistake with my markup or code, that mistake is immediately propagated to the live site, impacting user experience or bringing the site down altogether.
-Changes to my files are lost forever-if I decide that a previous revision of a file was better than one I’m currently using, too bad for me.
I’ve inserted the kevinpaulconnor.com files into a git repository, downloaded and installed XAMPP to my local machine, and created a staging.kevinpaulconnor.com subdomain. The new workflow will be:
-Design and develop locally against XAMPP on localhost. Commit changes into my local git repository. This repository is synched with staging.kevinpaulconnor.com, which is protected from non-me pageviews by http authentication. Push changes to the staging domain, and inspect for errors. If all looks well, push changes to the live kevinpaulconnor.com domain.
This workflow solves my three issues above:
-Git pushes will now handle all my networking traffic between local, staging, and live environments, securely.
-By designing and developing locally and then testing on the staging site, I can catch coding errors before they propogate to the main site.
-Git will keep permanent copies of all my site revision changes-if I decide to revert to a previous edition of a file, git makes this easy.
Today and last weekend I’ve been working on implementing these changes: kpc.com is currently in a local repository, staging.kevinpaulconnor.com is up, protected, and set up to accept one line git pushes from the local repository, and I’ve installed XAMPP and the developer tools. For the moment, the live kpc.com site hasn’t been touched. Over the next few weeks, I’ll be thinking about how to accomodate this blog in the new workflow (particularly the database), setting up XAMPP to enable purely local design and development, and integrating the live site into the git workflow. Exciting!
This script is extremely useful for a small subset of fantasy baseball players, and otherwise…not so useful.
I refactored the code completely this year. It’s much faster, and it now caches the information that it gets from Cot’s in your browser-improving subsequent load speeds considerably.
Starting to work on Android application development on the side. I have an iPhone through work, but I picked Android for two main reasons:
-I used to be ok at Java and I’ve never learned any Objective C. In my new job, I’m doing front-endy stuff on top of java code, for the most part. Since android runs on java, it’s an opportunity to blow off the dust, and let the Java stuff that I learn in Android help me at my main gig, and vice versa.
-Apple’s gated community approach to application development isn’t the way that I like to work. I don’t want to have to pay for their developer license and I don’t want them have absolute authority over whether my apps live or die. I think that there’s space for multiple approaches in mobile just like with desktop OS; if Android winds up in a Linux-y type place, I think I’m ok with that.
Some notes from my first half-day with mucking with this:
-There’s some confusion out there about which version of Eclipse to use-the one tailored for Java, or the Classic. The Android website recommends the Classic, some blogs (e.g. this one) recommend Java specific. It appears that some of the Java tools were buggy for Android development in E3.5; I downloaded 3.61 and I can’t find good information about whether this has changed. It is possible to develop Android apps without Eclipse, but you don’t get to use the Android Development Tools (ADT) plugin for Eclipse, that simplifies project creation and the build process, allows easy access to the Android emulator, and full access to the Davlik (like the JVM for Android) logs.
-When I first created a new project, I included an apostrophe in the application name-Kevin’s First Test. This isn’t automatically escaped and will cause build errors-I assume that you can change the value from one of the configuration xml files, but I just deleted the project and started over.
I’m working from Reto Meier’s Professional Android 2 Development to ease myself in. I’ll continue to post as I make progress and run into difficulties