Interacting a local git repository with a subversion one has been very useful and is very common on old projects. The way to do that is by using the git svn commands. But sometimes there are situations where there is one large repository with several projects as subfolders in that repo.
Using the standard svn cloning command:
git clone my_svn_repo_server.com/repository
Will checkout the whole SVN repository (all subfolders, hence, all projects) into your local machine. This can be very large if the codebase and history is big, and very slow to interact with, since getting your local repository updated will involve getting changes from all other projects.
To make git clone a subdirectory from an SVN repository, use the following:
This way you not only clone that subdirectory, but also you will get updates from only that folder, making faster code pulls and pushes to the central SVN repository.
While I consider a very bad practice to have one large Subversion repository with several projects inside it as subfolders, I’ve come across such setups several times and it drove me crazy to have to checkout the whole thing. Hope this helps out.
Recently I’ve been working on a project for a client that makes use of CSS3 columns in its layout design. The problem with CSS3 columns is that it’s not supported by any stable version of Internet Explorer so far (surprised? no? good!). At the time of this writing IE9 is the latest version.
Luckily there’s hope. The CSS3 Multi-column script helps render columns in browsers that do not have this capability. All you need to do is download the file and add it to your HTML after all your stylesheet declarations. It will read all your CSS3 column declarations and render the content accordingly.
The script uses some crossdomain ajax calls to work its magic, but IE8 does things differently. I’ve patched the library with the fixes needed for it to work correctly in IE8.
Editing CSS in Emacs is very easy since the standard CSS mode comes included by default. But developer Julien Danjou created this nice minor mode called rainbow-mode which will display the color of the code as the background of the code’s text. It is very useful to immediately see the colors right there in the style sheet instead of trying to remember each code and then test in the browser window.
One of the problems I had was when opening any CSS file, it would open by default css-mode, but I had to manually load rainbow-mode every time. The elisp function auto-mode-alist is used to detect a file type by its name and running a function associated with it, generally the function to enable a major mode to edit that type of file. For minor modes I couldn’t find anything that would allow me to launch them without inhibiting the mayor mode’s startup.
So since auto-mode-alist takes a regular expression for the file type and only one function as its arguments, I wrote a function that will run both and use that as the second argument to execute.
;; CSS and Rainbow modes
(defun all-css-modes() (css-mode) (rainbow-mode))
;; Load both major and minor modes in one call based on file type
(add-to-list 'auto-mode-alist '("\\.css$" . all-css-modes))
Hope you find it useful and you like the combination of css-mode and rainbow-mode as much as I do.
Head JS A very interesting utility that will load all your js scripts (jquery, google analytics, etc) in parallel so page load times get shorter, plus a lot of other nice features like new HTML5 elements styling in browsers that don’t yet support them like some versions of Internet Explorer.
Google APIs code playgroud I didn’t know you could play with all the Google APIs in a single webpage, testing your code as your write it.
HTML5 and Django form inputs How to render the new HTML5 input types with Django form classes. It doesn’t require much, really easy and fast.
Emacs as Python IDE A bunch of tips to have a good Emacs Python development environment. I personally don’t prefer IDEs, so I don’t use ECB but the rest is very useful.
Setting up a Python Environment Good advice for those coming from a PHP world and are getting started on Python development. I didn’t know about virtualenv until I had to deploy my first Django app on a shared host web server. Then it all made sense.
In a start-up environment, things happen so fast that there’s very little time to polish your tools. Code gets done undocumented, development team members come and go with different programming styles and tools, and the chaos just builds up as the business goes.
At some point, you can’t finish or maintain something because one team member left the company with the knowledge of the code and without documenting. You either have to spend time figuring out what was done and how it works, or rewrite all that unmanageable code. I’ve seen this scenario happen too many times.
Just as the saying goes: “Stand in the shoulders of giants”, using an open source development framework is essential for the following reasons:
– Access to lots of documentation, tutorials, forums, etc – Proven working code by a large user community – Everyone knows where to look when a certain change is needed – Development teams scale faster because new hires or people switching project teams can catch up and integrate to the team quickly – Benefit from patches and upgrades from outside your development team – Improve team productivity by not having to spend time writing basic common components from scratch every time
Even when using a closed source framework, you still get most of the benefits. Some companies prefer to build their own tools and frameworks. This approach will work out as long as they stay consistent and everybody agrees to use them in a standard way. But unless you’re addressing a very specific problem or facing a special situation, I recommend you not to reinvent the wheel and use one of the many existing open source development frameworks out there.
Here’s an old video of a chat with Steve Jobs, where he talks on how to improve productivity and saving time and resources in a development team, by eliminating lines of code to write and taking advantage of what is already out there.
Testing is a task every developer has to do eventually on any programming project. You can do it manually after writing all your code to see if it works as you intended, or better yet, before writing your code, using test driven development techniques that will save you time and frustrations down the road. One of those techniques is called Unit Testing.
Ideally, unit testing takes place before writing any code. Its a way to plan out how your functions, classes and objects will behave. The basic idea is that you plan the outcomes of each part of your program, then you write those parts to provide that outcome. So think of it as a black box that you will give some input and expect some output. This way you know how objects will be organized, what methods to write in each class, what needs to be their input and how are they going to output the results. Having all your code in tests will help you add new features, change or refactor parts of your code faster without the fear of breaking something else in your software. If you changed something and all your tests still pass, you’re good to go, if not, you can easily track down where the error is and what got affected.
PHP is famous for having spaghetti code and being too flexible that you can mess things out pretty fast, specially when you’re not an experienced programmer, or you have a team of developers with different programming styles and experience working on several components of the same project.
Although there are several unit testing frameworks for PHP, I’ll talk about SimpleTest since its very light, easy to install and easy to learn. Also, if you’re a Drupal developer, its the testing framework of choice.
To install it, go to the Simpletest download page and get the latest version. Extract the files to your PHP path, or use require_once() calls to the autorun file:
Here’s an example of a class’ tests (testfile.php):
/* test result is an array */ $this->assertTrue(is_array($result));
/* test correct number of output elements */ $this->assertEqual(count($result), 5);
/* make a different call with different parameter */ $result = $obj->getList();
/* confirm that output is always an array, even with 0 elements */ $this->assertTrue(is_array($result)); } }
Now you have a basic skeleton of you methods and their behaviors, now you can go ahead and write the real code (myclass.php).
Once we’ve written the class, we can test out its methods by running our tests script. You can do that by using the command line, or by viewing the php script in a browser window.
Personally, I prefer to use the command line for convenience and faster testing without needing even to setup any web server. Running it will look like this:
$ php testfile.php testfile.php OK Test cases run: 1/1, Passes: 3, Failures: 0, Exceptions: 0
This is a very small and simple test, but you can also test out the interface of your project. SimpleTest has a browser class that can perform some events like simulating browser visits, doing clicks on your interface’s links and checking the HTML structure of the web server responses.