Month: May 2018

First thoughts on Dell XPS 13 Developer Edition

A few weeks ago a Dell XPS 13 Developer Edition arrived on my doorstep.

Wait, what? I thought you were a Mac guy

I’ve been using a 15-inch MacBook Pro as my daily machine for ten years, but before that I was on a Dell running Ubuntu for a few years and I’m on Linux servers every day.

I’ve been looking for a smaller machine to use as a secondary/backup laptop. I thought about getting a new 13-inch MacBook Pro, but it sounds like Apple may refresh the line-up later this year or next year, so I decided to wait and then maybe replace my 15-inch with something from the new line-up, assuming they don’t do something stupid (I’m looking at you, Touch Bar).

I thought about a Chromebook, but that seemed too limiting. I know developers have been successful on high-end Chromebooks, especially if they are able to use cloud-based IDE’s, and there was a recent announcement about running Linux apps on Chrome OS, but I honestly would rather just run Linux.

I decided to get a Laptop that ships with Linux. Sure, I could buy any laptop that has good compatibility feedback and just install it myself, but I figured, why not let someone else do that work for me. I quickly narrowed down the list to System76 Galago Pro and Dell XPS 13 Developer Edition (model 9370). After reading lots of reviews I decided to go for the Dell. I like System76 as a company, and I hope to buy some other hardware from them in the future, but the XPS 13 gets lots of great reviews in terms of build quality which is ultimately why I decided on the Dell.

This is a secondary machine, so I could have skimped on the specs to save some dough. Instead, I decided to provision the new laptop as if it were my primary dev machine to make it as useful as possible as a backup and roadie. If it’s anemic, I won’t use it, and the whole idea is to actually use the thing. When Apple eventually refreshes the MBP lineup, I want to make a good decision about whether to stay the course with MacBook Pro or make the switch back to Linux full-time.

Impressions after three weeks of occasional use

The Dell XPS 13 has an aluminum top and bottom with a carbon fiber deck. I was worried about the case not being all-aluminum, but that was unfounded–this is a solid machine. It’s small and light but has a sturdy, well-put together feel. The aluminum case and the black carbon fiber look pretty sweet. I can’t get over how thin it is.

I’m not quite used to the keyboard yet–I feel like I’m stretching to get to the left ctrl key and I consistently hit PgDn when I mean to hit the right arrow. The keys have more travel than I thought they would based on the thin case, which is good.

The trackpad is much better than I thought it would be–I had come to believe that only Apple could do trackpads right. I was wrong. The Dell trackpad is a pleasure to use. I will say that with its large size relative to the small deck and my big mitts, I’ve inadvertently palm-touched it more than once.

While researching the machine I saw several mentions of the thin bezel around the display, but I didn’t pay much attention to what seemed to me like an insignificant detail. That was until I opened the lid and fired it up. The display is simply gorgeous. I can’t stop looking at it, it’s so big, bright, and crisp. Comparing it to my daughter’s 13-inch MacBook Pro, I now get the bezel thing. The XPS 13 is basically wall-to-wall display.

I’ve always associated small laptops with lackluster performance, but, damn, this thing is super snappy. It’s got an Intel I7 8th Gen CPU with 8 cores that runs up to 4.0 GHz. Mine has 16 GB of LPDDR3 2133 MHz RAM and a 500 GB SSD. That’s a lot of punch to be packing in this small package. I’ve had the fan kick on a few times, like when I’m running several Docker containers, but most of the time it’s quiet.

There have been reports of “coil whine”–a high-pitched noise often associated with video cards–on these machines, but I have yet to hear it.

I haven’t given the battery a fair shake yet–the specs claim 19 hours, which seems like a stretch based on what I’ve seen so far. The charging adapter is tiny which I’ll really appreciate when I take it on the road.

This year’s model has two USB-C ports, a card reader, and a headphone jack which is plenty for my needs.

Enough hardware, let’s talk software

The XPS 13 Developer Edition ships with Ubuntu 16.04 LTS. I use Linux all of the time, so I wasn’t worried about being productive immediately on the OS. I suspect that developers considering a move from MacOS to Ubuntu (or other Linux distributions) would also find the transition easy, even if they rarely use Linux because their shared Unix heritage makes them very similar, especially from a command line perspective.

My biggest worry was VPN. It seems like every one of my clients uses a different VPN setup. Many of my clients already struggle to get my Mac connected, so I had low hopes for the Ubuntu machine. The results have been mixed–I was able to use a combination of OpenConnect and Shrew Soft VPN to get connected to most of my clients from the machine. Not all of them are working quite yet. (Ironically, connecting to VPNs based on Dell SonicWall have given me the most trouble).

Other than VPN, getting everything else set up was smooth. I’ve had no problems installing the most critical software: Firefox, IntelliJ IDEA, Atom, VirtualBox, Docker, Pidgin, Retext, Java, Maven, and NodeJS all installed without incident.

I thought for a second I wouldn’t be able to use my Yubikey because of the USB-C ports, but Dell ships an adapter and that worked great, as did the Yubikey GUI.

I’m super happy with the machine so far–it’s going to meet my requirements quite well. Whether or not I come full-circle and return to Linux as my primary daily development machine OS will depend on my eventual success with VPN as well as what Apple decides to do with the MacBook Pro line-up. Until then, I’m enjoying this little beast.

Alfresco User Interface Options Revisited

Alfresco has been working hard on its new Application Development Framework (ADF), which consists of a client-side JavaScript API and a set of Angular components (see “Alfresco embraces Angular: Now what?“).

Alfresco says the ADF is now ready for production use (as of the 2.0 release) and they’ve also been iterating on an Example Content Application that shows how to use the ADF to build a general document management application.

Many of my clients are watching the ADF closely. Some are dabbling with Proofs-of-Concept, but few have started building their own ADF-based applications. One reason is purely practical–the ADF requires release 5.2 or higher, so an upgrade (or two) stands in the way of production ADF use.

The other reason is more strategic, and it centers around whether or not a customer should expect a content services platform vendor to provide a user interface, and, if so, what kind, or whether that should be the client’s responsibility. This is still being worked through, both internally and externally (see “Future of Alfresco Share Remains Foggy After DevCon“). Alfresco has been very open about their plans and has been gathering input from customers so we’ll see how it plays out.

Customers that require user interface customizations today may feel stuck–extensive Share customizations don’t make sense at this point, ADF requires 5.2, and, even if that’s not the problem, the amount of work required to assemble a solution using the framework and to maintain it going forward may not make sense, especially if what is needed is just vanilla document management with some UI tweaks. (I’m not saying “Don’t use ADF”–I’ve been lobbying for it since 2010. I’m just saying it might not make sense for everyone, for all use cases).

Nine years ago (yikes!) I wrote a post called “Alfresco User Interface: What Are My Options?“. It’s probably time to revise the list. If you need to provide custom functionality on top of Alfresco today, here are your options:

Use the ADF

If you are running 5.2 or higher, clearly, this is what Alfresco would recommend. It ships with components based on Angular, which I’ve been using for a while now and I really like. But, if Angular isn’t an option for you, you can leverage the client-side JavaScript library that is part of the ADF and use React or whatever you want.

And you don’t have to start with a blank app–you can use the Example Content Application as a starting point, if it’s close to what you need, or just as a learning tool if it isn’t.

Advantages:

  • Ready-to-use components save you a lot of work
  • Components and client-side JavaScript API supported by Alfresco
  • Angular is a popular framework, so there should be a lot of developers who can help
  • Client-side JavaScript API lets you use something other than Angular if needed
  • Heavy focus by Alfresco engineering means that new components and features are being added frequently

Considerations:

  • Requires Alfresco 5.2 or higher
  • While the components are extensible, you must stick to the extension points and not customize at the component source code level, unless you want to fork the framework (or at least that component) and maintain it going forward
  • Angular components are styled with Google Material Design which may or may not be aligned with your look-and-feel standards
  • If what you really need is Share with a certain set of customizations, it may be more work to re-build Share-like functionality using ADF components, at least in its current state

Use Your Own Framework

I’ve done several projects with custom, non-ADF Angular components hitting an API layer implemented with Spring Boot. The API layer talks to Alfresco via CMIS, the Alfresco REST API, custom web scripts, or some combination. The API layer also talks to other systems, which is important because these apps are rarely just about Alfresco alone.

I’ve been using Angular but you can obviously use whatever front-end you want. You don’t have to hit an API layer–you can hit Alfresco directly from your client-side JavaScript–the architecture, the tools, and the entire stack is up to you.

The nice thing about this approach is that it works with older versions of Alfresco. And the application only includes exactly what you need to meet end-user requirements. Of course, you have to build all of it yourself and maintain it going forward.

Advantages:

  • Total flexibility in the toolset and architecture
  • Meets your exact requirements

Considerations:

  • Custom code has to be written, debugged, and maintained
  • If you choose an esoteric or short-lived framework, you may be re-writing the application sooner than planned

Use a Commercial Front-end

I’ve seen some very slick commercial front-ends of late. If your main problem is presenting a compelling user interface for finding content, take a look at Alfred Finder from Xenit. It’s got some really impressive features for building and saving queries and a blazing fast user interface. Finder, as the name implies, is read-only. If you need to create content you’ll have to talk to Xenit about a customization or use something different.

For something more specific to case management, take a look at the OpenContent Management Suite from TSG. TSG has removed the hierarchical folder metaphor entirely. Instead, content just goes where it needs to go based on user role, the type of content, and the task at hand. The focus here is on end-user productivity where end-users are most likely case workers, records managers, or similar. (Despite TSG’s proclivity to use “Open” in its branding, this is not an open source solution. You must be a paying TSG consulting customer to use it and to see the source).

If your use case centers around forms, take a look at FormFactor. This isn’t a full replacement front-end like the previous two, but a lot of the customizations people do are really there to support custom data capture, so I’m including it because it might eliminate the need to do any customizations at all. FormFactor allows non-technical end-users to build and publish electronic forms via drag-and-drop, all within the existing Alfresco user interface. The demo I saw was built on top of Share. I’ve asked FormFactor via Twitter whether they will be able to support ADF-based clients as well but have not yet heard back.

Advantages:

  • Commercial add-ons offer shorter time-to-value
  • Maintained by a vendor
  • Functionality leverages the collective feedback of the vendor’s customers

Considerations:

  • May involve up-front license cost and/or annual maintenance fees
  • Commercial products are often shipped as-is, with a close, but not exact, fit to your requirements
  • Support SLA’s can differ widely from vendor-to-vendor
  • Generally speaking, working with your procurement department may not be considered one of the simple joys of life

Customizing Share is Not a Long-Term Option

Despite the announcement that parts of Share are being deprecated and the recommendation for all custom development to use ADF (announcement), I expect the Alfresco Share client to be around for quite a while. The transition to whatever comes after Share is likely to be lengthy and orderly. No timeframe has been announced, but my guess is this will be measured in years, not months.

So if you have a custom action here or there, or you want to remove a few features to streamline a bit, you should do so.  However, if you’ve got major Share renovations in mind, like stripping it down to the studs and knocking out a load-bearing wall or two, you are going to spend a small fortune on what will someday be throwaway work. Instead of doing that, think carefully about using one of the alternative approaches I’ve outlined in this post.

UPDATE: I changed all occurrences of “AngularJS” in this post to “Angular” to make it clear that what Alfresco uses (and what I’ve been using on my own projects) is the newer version of Angular that used to be known as “Angular2” but is now referred to just as “Angular”.

Photo Credit: wireframe, ipad, pencil & notes by Baldiri, CC-BY 2.0