Name: Kathleen Bruce

Hometown: Annapolis, MD, USA

Alma Mater: UMBC

The following is a guest post by by Tobias Günther. Tobias works for Tower, the Git client for Mac and authored the new (free) book Learn Version Control with Git - A step-by-step guide for the complete beginner. Tobias is going to share a bit of information about a very uncomfortable moment when using Git: the merge conflict.

Everybody has a list of things they don't like: an appointment at the dentist, a traffic jam, or a canceled flight. When I was preparing my book, I wasn't surprised that a lot of designers and developers would add merge conflicts to this list without hesitation.

When using Git for version control, there is nothing to fear. Once you understand how merge conflicts work and how to deal with them, I'm sure you'll be able to cross them off this list.

You Cannot Break Things

The first thing that you should keep in mind is that you can always undo a merge and go back to the state before the conflict occurred. You're always able to undo and start fresh.

If you're coming from another version control system (e.g. Subversion) you might be traumatized: conflicts in Subversion have the (rightful) reputation of being incredibly complex and nasty. One reason for this is that Git, simply stated, works completely different in this regard than Subversion. As a consequence, Git is able to take care of most things during a merge - leaving you with comparatively simple scenarios to solve.

Also, a conflict will only ever handicap yourself. It will not bring your complete team to a halt or cripple your central repository. This is because, in Git, conflicts can only occur on a your local machine - and not on the server.

How a Merge Conflict Occurs

In Git, "merging" is the act of integrating another branch into your current working branch. You're taking changes from another context (that's what a branch effectively is: a context) and combine them with your current working files. Have a look at this introduction to branching if you're new to the concept in general.

A great thing about having Git as your version control system is that it makes merging extremely easy: in most cases, Git will figure out how to integrate new changes.

However, there's a handful of situations where you might have to step in and tell Git what to do. Most commonly, this is when there are changes to the same file on both branches. Even in this case, Git will most likely be able to figure it out on its own. But if two people changed the same lines in that same file, or if one person decided to delete it while the other person decided to modify it, Git simply cannot know what is correct. Git will then mark the file as having a conflict - which you'll have to solve before you can continue your work.

How to Solve a Merge Conflict

When faced with a merge conflict, the first step is to understand what happened. Did one of your colleagues edit the same file on the same lines as you? Did they delete a file that you modified? Did you both add a file with the same name?

Git will tell you that you have "unmerged paths" (which is just another way of telling you that you have one or more conflicts) via "git status":

Conflict Markup

Let's take an in-depth look on how to solve the most common case: when two changes affected the same file on the same lines.

Now is the time to have a look at the contents of the conflicted file. Literally open it in your code editor. Git is nice enough to mark the problematic area in the file by enclosing it in "<<<<<<< HEAD" and ">>>>>>> [other/branch/name]".

The contents after the first marker originate from your current working branch. After the angle brackets, Git tells us where (from which branch) the changes came from. A line with "=======" separates the two conflicting changes.

Cleaning Up

Our job is now to clean up these lines: when we're done, the file should look exactly as we want it to look. It can be necessary to consult the teammate who wrote the conflicting changes to decide which code is finally correct. Maybe it's yours, maybe it's theirs, or maybe a mixture between the two.

Opening the raw file in your editor and cleaning it up there is perfectly valid, but not very comfortable. Using a dedicated merge tool can make this job a great deal easier. You can configure your tool of choice using the "git config" command. Consult your tool's documentation for detailed instructions. Note that just because you have git installed doesn't mean you have a dedicated merge tool installed, these are separate, optional software tools.

Then, in case of a conflict, you can later invoke it by simply typing "git mergetool".

For this example, I've used Kaleidoscope on Mac:

The left and right panes stand for the conflicting changes; a far more elegant visualization than <<<<<<<" and ">>>>>>>".

You can now simply toggle which change shall be taken. The middle pane shows the resulting code; in good tools, you can even edit this further.

Now, after cleaning up the file with the final code, all that's left is to save it. To give Git a hint that you're done with this file, you should quit the merge tool to continue. Behind the scenes, this told Git to execute a "git add" command on the (now formerly) conflicted file. This marks the conflict as solved. Should you decide not to use a merge tool and instead clean up the file in your editor, you'll have to mark the file as resolved by hand (by executing "git add <filename>").

Finally, after resolving all conflicts, a merge conflict situation needs to be concluded by a regular commit.

How to Undo a Merge

As already said, you can return to the state before you started the merge at any time. This should give you the confidence that you can't break anything. On the command line, a simple "git merge --abort" will do this for you.

In case you've made a mistake while resolving a conflict and realize this only after completing the merge, you can still easily undo it: just roll back to the commit before the merge happened with "git reset --hard <commit-hash>" and start over again.

Tools Can Make Things Easier

I've already mentioned it briefly: being equipped with good tools can make your life quite a bit easier. A proper merge tool will help you better understand a conflict scenario and make the right decision.

Have Confidence

With all the safety nets in place that Git provides, there's really no need to be afraid of merge conflicts in any way. Once understood how they work and what your options are, you should be ready to merge like there's no tomorrow. Always keep in mind: you can't break anything!

Note from the Editor

Tobias modestly left out Tower as an excellent tool to help with merge conflicts. In fact one of the reasons I personally use Tower is because I like how it helps with with merge conflicts.

It's very clear when you have a conflict:

And right-clicking on the conflicted file gives you some nice options:

So my process is usually:

1. Is it very obvious to me whether my changes to this file or the other branches changes to this file should "win"? If so, select the relevant "Resolve <file> Using Mine" or "Resolve <file> Using Theirs"
2. If I need a closer look, pop it open in a code editor and check it out. Then maybe still I can use one of those options.
3. If it's more complicated, manually fix it up and then choose "Mark <file> as Manually Resolved" from Tower.
4. Sometimes use a Merge Tool if there is a lot of complex fixes, which Tower also supports opening conflicts in via the "Open <file> in Merge Tool" option.

How to Deal with Merge Conflicts in Git is a post from CSS-Tricks

Starting with just a simple line of code 11 years ago, WordPress has evolved to become the platform of more than 74 million websites.

Even with a vast array of competitors offering similar functionality, WordPress still dominates the CMS market with a 21.9% market share.

I have had a more detailed look at WordPress than most.

I have contributed to 6 releases of WordPress, including work in the XML-RPC API (in 3.4) and WP_Image_Editor class (in 3.5). I have also been involved in an upcoming release (3.9).

As we look toward the future of WordPress, it is important to evaluate current practices and trends within the WordPress user base, as well as the industry as a whole.

In this article, I will discuss my predictions and opinions regarding the future of WordPress.

Moving with Demands

Recently, the demand for advanced features has been increasing as more and more developers are using WordPress to build mobile apps and complex e-commerce websites.

While WordPress already delivers many solutions for advanced use-cases, changes in consumer behavior will consistently affect the demand for unique plugins and ongoing enhancements.

WordPress as a Mobile App Backend

The uptake of mobile technologies is on the rise. 58% of adults in the U.S. currently have smartphones according to the Pew Research Internet Project.

Emerging solutions such as the AppPresser plugin — a finalist in the 6 About to Break competition at MacWorld 2014 — are allowing users to create mobile apps using WordPress.

This current consumer trend towards mobile presents an opportunity for WordPress to capitalize on the shift toward mobile development.

By incorporating a RESTful application programming interface (API), current WordPress apps could be supported, as well as mobile apps that use WordPress as a backend.

WordPress as a Development Framework

WordPress has been placing a large focus on providing the best user experience possible. And, in my opinion, it has succeeded in this goal.

Moving forward, I see the concentration shifting toward evolving WordPress into a full CMS and application framework.

Right now, WordPress does a splendid job as a content publishing platform, as evidenced by its use by the major online magazines, journals, and blogs. Time magazine, CNN, Forbes.com, Wired, and TechCrunch are just a few examples of web properties that rely on WordPress.

However, more complicated use-cases like online stores, mobile app development, and web app development require plugins, heavy customization, and development.

The next step is to evolve the platform to make it a more robust CMS/app framework that can make more complicated use-cases easier to produce for developers.

Dealing with Legacy Code

While the system currently offers users a wide range of features and possibilities, WordPress will update its legacy code and deliver new APIs to ideally fit the needs of web developers.

If an emphasis is placed on this area, the biggest challenge will be streamlining the codebase while building a solution that ensures backwards compatibility.

Considering the first version was released over 10 years ago, achieving this objective is likely to be quite a huge undertaking.

Where WordPress Doesn’t Need to Change

The past few years of success have truly proven the knowledge, experience and passion found within the WordPress community.

We have worked together to accomplish great milestones and made the impressive strides that have advanced WordPress to become the most popular Web platform across the globe.

The WordPress community will play a large role in the continual development of the platform to best suit its users’ needs.

Related Content

• Lessons Learned Building a SaaS with WordPress
• 10 Basic Tips for Improving WordPress Themes
• WordPress Theme Frameworks: Options You Should Consider

About the Author

Marko Heijnen is a 1&1 WordPress specialist and a contributor to the WordPress community. He’s had a hand in developing 6 releases (3.0, 3.4, 3.5, 3.6, 3.7, and 3.8) and the upcoming 3.9. Some notable contributions include working on XML-RPC API and WP_Image_Editor. He’s also the main core developer for GlotPress and is currently creating a better open source tool for translations. As a 1&1 WordPress specialist, Marko is committed to improving the platform by contributing back to the community. Visit his site markoheijnen.com and follow him on Twitter: @m arkoheijnen.

The post The Future of WordPress appeared first on Six Revisions.

Bookstores are closing, newspapers are folding and magazines are rushing to publish online. The stock of print media seems to be falling, but two Japanese designers are challenging that process with a newly released collection.

Masahiko Sato and Tatsuya Saito’s exhibit, “Putting Finger,” examines how viewers needn’t be passive bystanders where print is concerned; instead, their illustrations allow the onlooker to have a hand, quite literally, in the finished product.

The idea is simple, the illustrations don’t appear to be complete without the viewer’s interaction. Once you place your fingers on the appropriate ‘hit areas’ the illustrations take on new tensions and dynamics. The interaction is completed by the touch of the viewer; quite a unique approach to print.

The series is on display at the DDD Gallery in Japan until April 26, 2014.

100+ High-Quality Premium Themes & Templates – only $27!

The latest, highly anticipated version of Sketch by Bohemian Coding, has just been released. It’s an application that has promised much in the past, with many designers embracing it wholeheartedly. However, the previous two versions felt too immature for professional-grade work; the question is, has version 3 addressed those concerns, and is Sketch ready to be used as the go-to design app for creative studios?

The first thing to note is that unlike some pretenders to Adobe’s crown, Bohemian Coding are a professional operation who’ve been working on the various iterations of Sketch for six years, which in Web years makes them old-hands. Sketch is a stable product with relatively few bugs and, as far as I can tell in the time since version 3′s release, the latest version is equally well made.

Where Sketch really excells is creating UI graphics. It’s the market that Bohemian are aiming for. With Fireworks shuffling off in the direction of the trashcan and Photoshop being repurposed as a bloated 3D generator then there’s certainly a niche to fill.

Drawing comparisons

Sketch officianados almost invariably compare Sketch to Photoshop but it’s a comparison that doesn’t really hold water: the two applications are built for completely different purposes, a more appropriate comparison can be made between Sketch and Fireworks. And seemingly it’s from the Fireworks community that most Sketch fans originate.

It would be naïve to pretend that direct comparisons between Photoshop and Sketch won’t continue to be made, but that is largely due to the ongoing (mis)use of Photoshop as a web graphic creation tool.

Compare Sketch with Fireworks and you’ll quickly draw some interesting conclusions: firstly, Sketch’s GUI is far simpler than Fireworks’ and the improvements made to Sketch 3 only serve to widen that gap; secondly, Sketch is a contemporary web tool, it’s not running off assumptions made by Macromedia back in the 1990s; thirdly, Sketch offers a similar mindset to Fireworks, but with an ongoing commitment to development, whereas Fireworks—rightly or wrongly—is barely clinging to its slot in the Creative Cloud lineup.

Exporting from Sketch

One of the more popular features in Sketch is the @2x export option. This allows you to export a larger version of your image for retina displays. However, if you’re working in vectors, then you can export at any size from Photoshop, and if you’re working in bitmaps, then Sketch is no better off. However, I do like the simplicity of Sketch’s export options, even if I maintain that all vector art should be rendered as SVG (which by the way, Sketch can do).

In order to make a direct comparison I drew a vector circle with a gradient fill in Sketch, Photoshop and Fireworks, exporting it twice from each application at 244 x 244px and 488 x 488px. The results were unexpected: Sketch’s two files came in at 53kb and 197kb; Photoshop’s were 44kb and 165kb; Fireworks’ were 8kb and 22kb. That, in the modern parlance, is known as a beating. Of course, the test was heavily skewed towards vector programs, and I wasn’t surprised that Fireworks did so well, I was a little surprised at Photoshop’s triumph however. Had I been saving a complex bitmap I’d expect Photoshop to have done even better.

What’s more, whilst Sketch’s primary export option is slicing, Photoshop’s is now the generate feature, a process by which layers are exported live when altered. Given the iterative approach of most design processes, that’s something that Sketch is sadly lacking—perhaps in version 4.

Sketch’s saving grace in this respect is that it allows direct access to CSS properties associated with elements, meaning you may not need images for your layouts at all.

Embracing CSS logic

The biggest success in Sketch is that Bohemian have embraced the logic of CSS. When Photoshop was first released CSS simply didn’t exist, even so, it’s hard to envisage how Adobe managed to settle upon such arbitrary settings—when people are releasing whole sites to help designers convert a Photoshop drop shadow to a CSS drop shadow, then someone at Adobe HQ should be able to spot the hole in their product. Fireworks performs a little better, but Sketch’s lack of baggage means that Bohemian have been able to build an app more in tune with how contemporary designers work.

Certainly type aficionados will appreciate not having to pick one of Photoshop’s irrelevant anti-aliasing options.

There is something to be said not just for the efficiency, but for the experience of using an application, and whilst it’s hard to be objective after so many years of Photoshop use, Sketch’s CSS approach certainly feels neater. The consistency with a front-end coding mindset is one of the great successes of Sketch. It just works.

What’s wrong?

There are unfortunately some questionable choices in Sketch 3. Why, for example, has such emphasis been placed on creating reflections of elements? Reflections are an intensely dated design crutch and aren’t worth a second thought (unless you’re part of the in-house team at Apple, in which case they’re part of your brand guidelines). I’m not so much questioning the inclusion of reflections, rather the decision to make such a feature of them when they could have been tucked away somewhere inoffensive.

Another let-down is Sketch Mirror, an additional purchase from the app store that allows you to preview your design live in your device—provided your device is an iPad or iPhone. Fans of Android will need to stick to Adobe’s Edge Inspect, which does the same job across multiple devices.

Those issues pale into insignificance when set alongside the fact that industry adoption of Sketch isn’t yet widespread. For individual designers, particularly iOS designers, Sketch may be a personal preference you’re entitled to act upon; but for designers working within a team, or delivering content to clients for development elsewhere, Sketch’s integration with existing workflow is limited. For the time-being, PSDs are still the industry standard, and when PSDs are eventually rejected it will be for in-browser design, to the detriment of all design apps, Sketch included.

Is it time to switch?

Sketch isn’t a must-have tool. It doesn’t compete with Photoshop for bitmap editing, and I’m surprised at how badly it handled exporting a vector; compared to Fireworks, its performance is a little embarrassing. It doesn’t have drawing controls as sophisticated as Illustrator, and it won’t play nicely with the workflow of anyone but a one-man design and code shop. However, Sketch is substantially cheaper than any of Adobe’s offerings. There’s a 14 day trial which I’d encourage you to take, especially if you’re one of the many who are still bemoaning  the demise of Fireworks.

All criticism aside, Sketch is a really fun tool to use. It’s really fast to create in, and the CSS logic means converting designs to pure CSS is blissfully easy.

Most designers won’t be switching to Sketch as a primary tool just yet, but as a secondary prototyping tool it excells, and the idea of Sketch replacing Fireworks (or Photoshop) isn’t as strange as it seemed a year ago; if Sketch 4 makes the same kind of in-roads that Sketch 3 has made then Adobe will be taking a long nervous look over their shoulder.

100+ High-Quality Premium Themes & Templates – only $27!

It’s Tuesday which means that the Treehouse Show is back! In episode 86 of The Treehouse Show, Nick and Jason (@jseifer) talk about writing good emails, detecting credit cards in JavaScript, and a sweet new JavaScript editor.

This Week’s Links

• Really Good Emails – The Best Email Designs in the Universe (that came into my inbox)

• Error Handling in Nodejs – Developer Center – Joyent

• Refills

• How to correctly detect credit card type

• Font-To-Width

• Speaking JavaScript

• EpicEditor – An embeddable JavaScript Markdown editor

• Debugging Asynchronous JavaScript with Chrome DevTools – HTML5 Rocks

The post Really Good Emails, Credit Card Detection, Epic Editor | The Treehouse Show Episode 86 appeared first on Treehouse Blog.

On Saturday, April 12 in Atlanta, History Associate Professor Kate Brown was awarded the 2014 Ellis W. Hawley Prize from the Organization of American Historians (OAH) for the best book-length historical study of the political economy, politics, or institutions of the United States, in its domestic or international affairs, from the Civil War to the present.

Brown received the award for her book, Plutopia: Nuclear Families, Atomic Cities, and the Great Soviet and American Plutonium Disasters (Oxford University Press, 2013), in which she tells the stories of Hanford, Washington and Ozersk, Russia. The Soviet and American governments created these communities to produce the plutonium that fueled the nuclear arms race during the Cold War.

In a press release announcing the award, OAH stated: “Brown notes that the major accidents at Hanford and Ozersk were largely unknown to the public, in contrast to the recognition today of Chernobyl and Fukushima. But the costs to the well-being of the workers and the environment were arguably far higher. This revelatory history provides a highly readable and deeply researched model of transnational history.”

Last month, Brown was awarded the 2014 George Perkins Marsh Prize from the American Society for Environmental History (ASEH), also for her book, Plutopia.

Washington, D.C. hasn’t directly funded its shadow delegation to Congress, the city’s official statehood lobby, since the first elections for the positions were held in 1990. However, just last week, Mayor Vincent Gray released a budget for fiscal 2015 that includes $100,000 for the delegation.

George Derek Musgrove ’97, history, assistant professor of history, wrote an op-ed in The Washington Post titled, “D.C.’s shadow delegation: It’s not the money, it’s the strategy,” in which he argued the money could help the delegation, but only if it changes its approach.

“Since its creation, the shadow delegation has focused its energy on lobbying members of Congress on Capitol Hill. Though its efforts get support from the small number of members who already favor statehood, the delegation has never been able to persuade those on the fence, let alone outright opponents, to support their cause,” Musgrove wrote.

Musgrove wrote in order to attain its goals, the delegation must learn from lessons in D.C.’s history, such as the campaign for the D.C. Voting Rights Amendment.

“The 2015 budget could give the shadow delegation funding it needs to expand its lobbying operation. But the history of the struggle for D.C. self-determination teaches that, to have any success, it needs to adopt a strategy that can reach the folks back home,” he adds.

To read the full op-ed in The Washington Post, click here.