One thing to consider if you’re worried about DRY is to version your cake/ directories separate from the app/ directories, and set cake/ as an external for each project-specific app/ folder you have.

Yeah, this is kind of what I had in mind except that this isn’t my own framework, of course. In your case, is “custom” code completely segregated or is it intermingled (to one degree or another) with the framework code? In the case of Cake, custom code is localized in a /app directory, but that directory also ships with code that may (or may not) be required for the application to work properly.

It’s that intermingling that is giving me pause since I’m not sure how best to represent only the intermingled custom code in source control.

I handle the “changes in framework” issue with specific versioning, so if I make a change to the framework that affects any of the interfaces a project might call, I’ll install a new mapping to a new version of the framework, so I don’t have a mapping to /lightbase – it is to /lightbase2 or /lightbase3. That seems to work fairly well for me.

I don’t much like throwing the framework code into the project repo, but it does depend how many projects you do, how much control you have over the framework, how your build process is set up, how easily you can separate framework code from project code, etc.

I think frameworks – especially full stack frameworks – have the ability to rapidly evolve or devolve a language experience. I do like Cake, although I’m mostly working the engineering side. I haven’t had much opportunity to get into the nitty-gritty and really write code (which is why I’m using it for a side project now).

Okay, so two smart people have intelligently rationalized something that I was doing anyway. Guess I’ll just stick with it pending any dissenting opinions that are sufficiently well reasoned.

btw… cakephp is pretty sweet eh? Using it briefly made me realize that PHP development has really evolved a lot since I last dabbled with it!

The reason I’ve always just committed everything is to make my build process easier via consolidation and maybe that’s the right way to go. It just seemed like there might be a better way, so I thought I’d see if my accidental readership had any thoughts on the matter. :-)

Joel makes a useful recommendation in support of new users:

“If there’s some reason you can’t complete the action, the menu item can display a message telling the user why.”

A simple tooltip in the interface would do nicely here, but visually, the menu item should appear disabled (grayed out, etc.).

However, apparently everyone’s mileage w/ Del.icio.us varies, otherwise this post wouldn’t have been necessary. ReadWriteWeb had an article about different bookmarking solutions a few weeks ago that might be of some use.

6 Great Tools to Save Links for Later

For most bookmarks, however, I rely on browsing tags or del.icio.us bookmark search. I’ve taken the time to bundle my tags and will periodically go in and prune and update my tags and bundles.

The del.icio.us add on for Firefox 3, has added import and export. It’s not sync, but I don’t really need it. I have only a dozen or so private/local links that I manually maintain across a few machines.

Although, I have to say, I’m much more likely to simply be able to remember an article enough to google it than I am to find it via my bookmarks. They’re simply a last resort.

I’ve got everything set up in a /root/company/client/project structure (I do a lot of freelance work for a couple of clients hense the structure) and basically svn is a mirror of my test server and that seems to be working well. I will be working on a few projects today so I will see exactly how well it works as the day goes on.

Thanks for the help, I truly appreciate it.

1. In some directory on your local machine, create a template directory. On my work machine (Windows), my path is C:\Projects\.template.
2. In that directory, create your top-level structure (/branches, /tags and /trunk). I’ve zipped up my entire template structure for your use, if you care to just unzip that into your new directory. Note that several directories contain empty text files that can be removed. They were added so that empty directories would be included in the zip file.
3. Import that directory structure to <path to your repository>/.template.
4. To create a real project, as you already stated, svn cp -m “Creating initial project structure from template.” <path to your template directory> <path to your target directory>. The target directory should not exist before copying. Subversion will create it. If it already exists, you’ll get unexpected results.

I should also state that for my purposes, I have one repository containing multiple projects. One of those “projects” is my template. If you’re trying to create a one-project-one-repository structure, this won’t work in exactly the same way.

I am just having a hard time visualizing everything I need to do/want to do. If you don’t mind me picking your brain a little more, I have a scenario that I want to achieve. I’ve been reading thru the svnbook and not getting a true picture of how to approach.

Basically I am already doing more or less the structure you have above minus the svn. And every thing is ran on my local machine and when a project is completed, I ftp it to where ever it is hosted. I would like to set things up so that when I create a new project I get the template you have, but not sure how to do that. Or am I being dense and it is as simple as creating the folders and doing svn cp trunk/ tags/ to move the files around?

Thanks for your feedback, it’s been a while since I’ve been this lost :)

You must be installing on Windows. Doing so on Linux is quite simple (although that may seem counterintuitive). :-)

Using my own (perhaps half-baked) terminology, /trunk is my “project root”. /trunk/html is my web root as you suggest. I checkout a copy of /trunk to my development environment. When development is complete, I export a copy of /trunk to my production environment. Since everything is just a copy, the code bases “co-exist” happily (mostly because they’re not co-existing at all).

From the way you’ve worded it, it sounds like you might be trying to point your web root directly to your trunk. If so, that’s not going to work. You really want to be running your production site against a snapshot created by an export.

I hope I understood your question correctly, but feel free to follow up if I didn’t.

I’m not sure that explained it very well, but I can’t think of a better way to phrase it at the moment.

Anyway, I’m trying to figure out how you are doing things, you say that the trunk/html is where the website resides. But when you set a site live and need to develop next version and are still working on the trunk, where is the live site residing? Ultimately we don’t people see our work in progress so I am assuming you do something to point to a branch, is this correct?

Thanks.

Both ways – at least the way I’m conceiving them – have some useful pros and some annoying cons which is why I was hoping that there was some governing body of API authentication models that could say, “Do it my way because my way is good and doing it any other way is punishable by public flogging.”

That kind of authoritative response would relieve me of an awful lot of responsibility for the solution I choose. :-)

Previously we had a system where the client application sent username/password, and then received a series of IDs, which correspond to userID, groupID and companyID. It would be trivial for a client to be hacked to bypass the login sequence, and attempt to access data with just an ID. Which could mean they could access administrator data if they chose the right ID.

It uses the login time, username, and IP address with a SECRET VALUE to generate an md5 hash which is the sessionID. This means they are non-sequential, and unlikely to be guessed.

Session hashes are stored in a database table, which is looked at when a session has is received as part of a non-login request, and the user is selected from this if the has is valid.

Oh, and all of this is done over an SSL connection. It is up to the client application to store the session hash/key/id, and attempt to re-login if an invalid session message is returned on any future request.

I don’t know exactly when this happened, but I only noticed it moments ago.

JS

Thanks for sharing this information. I’ll post my thoughts on 2.x once I’ve had a chance to work with it.

Thanks for posting your thoughts on Pulse. We value any and all feedback.

You mentioned knowing a new release of Pulse was out. Have you had a chance to give it a try? I ask because in Pulse 2.x, we’ve changed the IDE launch flow to take server connectivity entirely out of the loop for Eclipse startup.

Using any of the Pulse 2.x technology, you will not run into your described issue. Instead, you will be directly launching the IDE so whether on a plane or not, you can keep using your chosen software along with Pulse functionalities.

During the initial releases of Pulse (which it appears you are utilizing), having the Pulse technology as a blocking step to launch an IDE was both a performance hit as well as a potential reliability concern and we therefore changed that flow in Pulse 2.

Please let me know if Pulse 2.1 (available now) solves these issues for you, and please let us and/or the world know your thoughts on the matter.

Thanks again,
Jens
Pulse team

As for recharging, I literally couldn’t keep juice flowing. Whether the laptop was on or off, no light appeared on the magsafe connector.

Regarding #8, next time try taking the battery out of your laptop before plugging it in. This works in many cases, depending on how much of a power hog your laptop is. Another option that often (but not always) works is to use the in-flight power to charge up your laptop. It has to be switched off, but it at least might allow you to recharge while you sleep.

I didn’t really understand all the fuzz about DVCS. Not until I got to use it regularly.
We use SVN at work, but I’m using Git-SVN myself. Now that I got the hang of Git’s branching/merging, I realize how much SVN branches suck. I no longer have to remind myself what exactly I’ve been doing, and usually all I need to do is to “git merge my_branch”.

It’s well worth the try. Nobody really sees you’re using Git-SVN. It’s transparent.

I don’t think branches are particularly difficult, but since most work occurs on the trunk I tend to move off on a branch for those efforts that will impact the experience of other developers working on the trunk.

If I’m reading you right, one of the key differences between our experiences is that, using Svn, I tend to feel like I have to think ahead and identify those changes that should be branched before I start working on them. I don’t suppose that’s entirely accurate, but to the extent that I feel that way, I guess branches are more difficult.

I’m not sure that answers your question very well, but maybe it’s a start.

I use branches when I think, “Huh, I wonder if this will work?” Or, “Note to self, we’re going to upgrade soon and I’ll have to do this a different way.” Or, “Ugh, none of those changes I made are ready to go to production yet, I need to go back and slice these last few changesets into a branch and work on another feature.”

Small distances can seem very far away when you have to walk them.

They were probably using the keyword tracking feature of twitter:
track git

I think I’m with you on the matte screen. I brought home an office MacBook with a glossy screen just so I could see a side-by-side comparison (my MBP has a matte screen). I can guarantee that the reflection would make me crazy. I watch movies on the thing almost never. I code (and do other semi-productive things) daily.

Thanks for the input.

As you point out, the 15” is perfect for travel and most tasks, but when I need that extra space, I just plugin in in my office. The 17”‘s form factor is just way too big for me (though it is beautiful).

As for the glossy / matte, I love the matte because you can take the laptop outside in direct sun, or in pretty much any lighting condition and it works really, really well (for doing coding, image manipulation, writing, etc).

My wife has the glossy, and while movies look stunning, the reflection on the thing would drive me batty while trying to focus on work.

my 0.02 £

And, by the way, it’s about time you start writing again. :-)

I hope to write a similar post focusing on my experience adapting to a source control workflow.

That said, I’ve never actually seen Pownce. :-)

That said, however, my brief twitter experience has me considering the possibilities of similar platforms being used to provide mass services (or even organize mass games), rather than being just a highly public bulletin board.

Thanks.

You can create a project at assembla , then go to admin/tools and do “add git & trac” to get a git repo and a trac set up for you; I did it with mercurial and it was pretty easy.

And offshoring, although that could be considered a specialized type of telecommuting. I have a team in India, but I guess my point is that even with that team to consider, Git seems to solve problems that I don’t have. I was wondering what, if anything, I was missing. If I can find a free service offering Git hosting, I may move a project over and try it out in order to get some hands-on experience.

I’ll check out the tutorial you linked. It’s always interesting to see how others are using tools within their daily workflow. Thanks.

It was enlightening for me to read this tutorial about how the SymPy team uses mercurial to fix bugs and review code before checkin to the main repository.

1. Developing large, destabilizing features, and
2. Maintenance of current releases

As a result, my merging needs are minimal. If they became more sophisticated, then I might have to look elsewhere.

I do like the idea of offline use (even though I feel like my entire life is spent online), but I find it hard to wrap my mind around how it could work in a team environment. Maybe installing a process of daily merges with the “king” repository is all it would take.

The reasons for it, in my case, are threefold:

1. Reasonable branching and merging. Branching in svn is slow, but the real killer of it is that svn doesn’t remember when you branched. This means that, when you go to merge, you have to manually go back and recover the version at which you last merged, create a diff, and patch it back into the main branch. And god help you if you needed to merge just a few small changes from trunk back into a branch, and then a branch back into trunk. Who knows what was in there and what wasn’t? I’ve had to check, manually, thousand-line diffs and more or less click and pray. It’s a bad scene, and hacks like eazysvn are just evidence that it needs to be fixed.
2. Offline use. I was offline for a few days there, and not being able to check in was extremely frustrating. It also led to a huge checkin once I got back online, which defeats the purpose of version control in the first place. This is compounded by:
3. Committing chunks. Svn always assumes that you want to check in all of your changes to a file. Git/Hg, on the other hand, will (if you want) ask you about each change and whether you want to commit it, and make seperate patches for each chunk that you want to commit.
4. Svn is slow-moving. It takes forever to get changes into the main builds of svn; I found and hit a bug with locking that had existed with a fix for over a year that just hadn’t been put in yet.

All of these are leading me to try mercurial. As for accountability, in my opinion this is already solved by process and using decentralized source control doesn’t affect it much. Having a developer who only checks in to a local repo is exactly the same as having a developer who never checks in his code.

Since I always use small icons, that option was already selected on my upgraded browser which, of course, is why the button looks right – not because of any change.

Thanks for setting me straight, Bill. I’ll update the post accordingly.

1. The post intended to focus on style sheet organization rather than the browser incompatibilities and I felt like adding IE-centric style sheets would blur that distinction.
2. Like you, if I do things right, I can often get away without using IE-specific styles.

That said, they are usually a necessary evil. When I need them, I tow a pretty hard line about keeping them external themselves and including them with conditional comments. I choose this path because I always know why a rule was included if it’s in an IE file and I can easily remove any “hacks” when/if I decide I don’t want them any more. I’ll usually create an IE7 sheet first and then create an IE6 version if things still aren’t right.

I’ll admit, though, that I’m horrible about print style sheets. Unless specifically requested, all too often I’ll do everything I can to avoid creating them. I’m not proud of that – you’re right that it’s not all that hard – but in the interest of full disclosure, I give you my admission of failure. :-)

The two sheets you’re missing, IMHO, are a “fix-ie” style sheet and print styles. If I’ve done well with my global styles, the fix-ie version has less than ten declarations. The fix-ie keeps hacks separate and manageable and is called with a conditional comment.

Far too many sites with great content are killing too many trees. I don’t need the site menu or that monster banner when I’m printing a procedure. I try not to print often, and I always print double-sided pages, and it just ain’t that much more work to add a ‘display: none’ to screen elements that have no business being seen on paper.

I do think that the “many forms of presentation” he references are more than “theoretically interesting”, though. It’s pretty powerful stuff and, frankly, the web is not a traditional application platform. It’s part application, part marketing brochure (for better or worse). It’s also public-facing and, as a result, often the first impression of a company (or whatever) on a new customer (or whatever). That dual-purpose demands a certain amount of flexibility and produces a need for visual freshness.

CSS, albeit flawed in implementation, offers that. Now sites can make small or even wholesale changes to their presentation with minimal effort and without touching their structure or content. That’s a pretty cool thing, I think.

As for #1 – eh. I guess I’m just bitter about how bad CSS sucks. I do use it, because semantic markup really rocks, but the fact that you need a wizard who knows the quirks of seventeen browsers and how they improperly render comments (!!) in order to get a layout possibly maybe correct is very frustrating.

I’ve actually been having a pipe dream of implementing a better web layout language that aggregates the best parts of LaTeX and Postscript and PDF into something designed with the web in mind instead of print. What a cool project that would be!

Can’t agree with #2, though. The fact that the web ever worked with that kind of “looseness” is actually disturbing to me. Should C, PHP, etc. work without a closing “}”? Should Python work without proper indentation? Personally, I think not. Languages, whether programmatic or structural should have rules and should enforce those rules. Anything else opens the door to ambiguities that in turn force systems to make assumptions. In my mind, that’s never going to be a good thing.

I understand that this is more problematic for users when dealing with interpreted languages, so C (as a compiled language) was probably a bad example above. C users would never see the error caused by the lack of a closing “}” since the compiler would catch it, but I still think the principle applies.

That said, I’ll dig into the URIs you posted later tonight. I have a lot of respect for both of the authors. Perhaps I’ll have my mind changed as well.

1) CSS is a poor standard that is implemented amazingly inconsistently across browsers, relies on wicked hacks to function, makes many simple things difficult and ignores brilliant prior art in the area. (Knuth? Anyone?) Finally, with CSS 3.0, it’s getting somewhere near usability, but who can actually rely on CSS 3.0? Hell, can I really rely on CSS 2.0 to work?

2) The web works because of the looseness of HTML tag soup, and refusing to render a page because of a missing / at the end of a tag is terrible for users. It makes developers feel good to raise themselves up to the bar of XHTML compliance, but it’s intentionally fragile for no particular reason. In fact, that’s what I’ll call XHTML: web developer pullups.

(Not that it wouldn’t be nicer for me if all pages were valid XML!)

I give you Mark Pilgrim, who is much smarter than me, with his classic on XHTML: http://diveintomark.org/archives/2004/01/14/thought_experiment which was so good that it changed John Gruber’s mind on the matter, in another excellent article: http://daringfireball.net/2004/03/dive_into_markdown .

Semantic markup rocks though, I won’t disagree with that.

One thing worth noting is that the DC Design Talks are part one of a three/four (we’ll see) part annual series that segments the DC web community into concentrations. In the late spring, we’ll be holding the DC Developer Talks, which will focus on back-end development (php, django, rails, etc). In the summer, DC Strategy Talks will cover folks who do high-level planning of web sites and businesses. So as a developer, you really weren’t a part of our target audience for this event, and our goal was to make this more purely about design. Hopefully, you’ll be interested in attending the event for developers, which is more likely to be your speed.

Because this was the first event, and we had an audience different from the normal Refresh DC crowd, we felt that a somewhat elementary CSS primer was appropriate, just for the many graphic designers in the audience who had never touched markup. For those of us familiar with the material, the hope was that it offered a perspective on how to talk about CSS, how to teach designers how to think in CSS, and perhaps how to sell clients on its value.

Finally, we wanted to give less experienced speakers an opportunity to get out there and actually give a talk. It’s tough to break into the scene as a designer, and the best way to learn is to just start doing it. In this case, that meant taking a few risks on speakers, and trying to offset that by having seasoned veterans like Nathan Curtis, Jason Cranford Teague, Thomas Vander Wal, and Jackson Fox do their thing. While I agree that content and presentation were the weaker side of the event, I think I have a grasp on how I can mitigate that in the future by taking on more of a mentorship and coaching role. I still think the objective is a worthy one.

In the end, yes, we expect that content will mature along with the series (and the audience), and that next year’s Design Talks will take a more advanced approach. It will still likely lean toward pure design, as that’s really the segment we’re targeting, but it will address more sophisticated issues in that field.

Thanks for coming, and I do hope we see you out again.

Man, your mind fascinates me. Thanks again for sharing.

Guess I am just out of touch or something.

(This time I want to see the fading in.)

Your site looks pretty great, nice job with it.

If I could convince the TSVN guys to develop a Mac port, the Adium guys to develop a Windows port and anyone at all to develop a robust financial management package for Mac then my life would be just about perfect. Technologically speaking, at least…

(Why have you forsaken us!!!???) ;)