Getting beyond ‘Just Do It’

Sometimes I really do despair of the ‘Just Do It’ crowd…

In a previous post, I described the practical challenges faced by anyone starting out on something new, and used a few personal examples in my own work to illustrate this. I then made the huge mistake of asking for practical advice about this.

What I got back was a stream of utterly unhelpful garbage – most of it well-meant, but some sadly not – most of which could be summed up by three words: “Just Do It”. None of the people concerned seemd to understand a really, really simple point: if I already knew how to do it, I wouldn’t be asking for advice on how to do it – I would already be doing it. And in those circumstances, ‘Just Do It’ is not not so much not helpful as an outright insult. Sigh…

In amongst the unhelpful non-advice, there were indeed a fair few of the more blatant examples of smug-arrogant-insult-disguised-as-‘help’, such as “there can be such a thing as too much thinking”, and “if you want to do something, you’ll find a way; if you don’t, you’ll find an excuse”. If there’s a quick way to enrage someone who is trying to do something completely new, and has been doing so, damned hard, for way too many years with way too little income and way too much anti-support, that really has to be it…

So…

Let’s do the big-picture first, and then the small-picture part, okay?

The big-picture

Before we start, a brief aside for the ‘Just Do It’ folks: ‘Just Enough Architecture Up Front’ does not mean ‘No Architecture Up Front’. If we don’t do sufficient thinking up-front, we end up building something that is, by definition (and by stupidity…) inherently incapable of reaching the required aim.

An illustration in point: there are literally tens of thousands of projects ongoing across the world right now into exploring some form or other of ‘alternative currency’. Yet by definition, none of them will succeed in doing anything more than making the real problems worse. The actual problem-area is not about the structure of ‘currency’, but that currency itself is merely an overlay on top of an existing ‘wrong-answer‘ (short-termist exclusive-possession) to a significantly deeper challenge (managing finite resources over the long-term on a finite planet). By definition, all of that effort on ‘alternative currencies’ is a total waste – and worse, it’s taking energy away from where we really need to place it –  because we urgently need a viable ‘right-answer’ to that resource-management challenge before those irreplaceable resources really do run out.

So, here’s the big-picture of what I’ve been talking about, about ‘the app’ or whatever:

— 1. There is an identifiable need for some kind of tooling that supports the whole of the workflow and context of enterprise-architecture and related fields – in effect, anything that links across and through the whole cycle from before strategy to after operations and back again, fully recursive at every level across the entire scope. We could summarise the overall scope and need with the Five Elements frame:

— 2. The key problem being addressed here is fragmentation of views over that whole scope, and across all of the different timescales, from far-future to near-future to NOW! to past, and back again. Plenty of tools already exist to cover single subsets of the overall scope, but incompatibilities between them mean that at present there is no way to create any kind of unified view. Without that unified view, we automatically devolve to increasingly-ineffectual ‘Just Do It’ dysfunctions that are inherently-unable to deliver against the actual need.

— 3. Specific model-types and metamodels will be needed in order to cover the specialist needs of subsets of that overall space. More particularly, it should be self-evident that no single model-type or metamodel will be able to cover the whole of the space, other than at a level of abstraction that is unlikely to be much practical use. However, some means to unify across the whole space is required, in order to prevent fragmentation. There is therefore a requirement to balance across all levels of abstraction, from most-abstract and most-unifying to most-concrete yet most prone to fragmentation.

— 4. As part of the necessary ‘Just Enough Thinking Up Front’, I’ve already spent several years exploring the needs for whole-of-context tooling, including use-cases, metametamodels and metaframeworks. I’ve done a lot of observation of real-world workflows across the whole of the context-space, in order to understand where tooling could help in unifying across those workflows, versus where (as in fact occurs too often in practice at present) tooling will increase fragmentation or just get in the way.

— 5. Any tooling will need to cover and/or be able to support the whole of the toolset-ecosystem that is actually in use across the whole context-space, from petabyte-plus big-data repositories, all the way down to almost-‘dumb’ handhelds. The scale is so huge that no one manufacturer or toolset-developer could ever expect to cover it all – yet overall, failure to cover the whole of the toolset-ecosystem will, by definition, cause failure to deliver to the actual need. This implies a need for non-proprietary standards that focus primarily on the ‘between’-space – the linkages between the discrete elements or ‘solutions’ in their respective subsets of the overall context-space.

There’s more to it, of course – a lot more to it, including why tackling this issue properly could well be a species-survival issue for us all  – but that’ll probably do for a start?

And I repeat: any so-called ‘solution’ to these requirements that fails to link across the whole of the context-space will not satisfy the actual need.

And yet, equally obviously, we’re not going to be able to deliver all of that in one go. So what do we do?

The answer: start small – yes, that part would sort-of-satisfy the Just Do It brigade – yet whilst keeping always the whole always in mind – which is the part that the Just Do It brigade tend to forget…

Between big-picture and small-picture

Some folks – the MIX crew, for example – might describe this kind of big-picture requirement as a ‘moon-shot‘. Which perhaps leads to a useful analogy here, about the difference between a firework rocket, versus the kind of real rocket-science needed for a rocket that really can lift something towards the stars. The ‘Just Do It’ crowd are really good at giving us millions of metaphoric firework rockets: and whilst the result may be very pretty, and probably very profitable for some, it doesn’t deliver against the actual need.

The only way that ‘Just Do It’ it will deliver anything useful towards the actual need is if we keep the big-picture in mind at all times whilst working on any part of the small-picture.

So, here’s the mid-range of the moves I’ve made towards that whole-of-context tooling requirement:

— There is no existing tooling that comes even close to satisfying the need. Probably the nearest would be something like an expanded version of Evernote: hence it might be sort-of-possible to do some kind of plug-in for Evernote that might sort-of do sort-of some of the need. The catch is that, like just about everything else that I’ve looked at over the past few years, it’s a proprietary file-format, it’s constrained in terms of what parts of the ecosystem it can and can’t support, and I don’t have a clue where to start plug-in development for Evernote anyway.

I have a lot of research-notes on what’s needed. Many of these I’ve published on this blog, if anyone has any interest in doing anything more useful than putting me down yet again – see, for example, the post ‘Five EA app-ideas – anyone interested?‘ and all of the links that come out of that post.

— Almost no-one is likely to take it seriously unless I have some kind of first-level demonstrator to show. Which is why I’ve doing a lot of work towards getting some kind of prooof-of-concept together. Which is where we get down to the small-picture.

The small-picture

For the purposes of building at least some kind of concept-demonstrator that might just possibly keep the ‘Just Do It’ crowd at bay, I’ve been pulling a whole load of strands together.

Any ‘real’ toolset will need serious-level security, reliability, performance, and much else besides. I am not the right person to attempt to do that. I can code, sort-of, but most of my detail-level knowledge is way out of date, and was never too wonderful to begin with. What I can do is knock up something that makes enough sense for someone else – who does know what they’re doing, with code and the like – to ‘get it’ as to what I’m on about here.

(The reality, once again, is that whoever actually ‘gets it’ first will probably make an absolute fortune out of it, whilst once again I’m likely to end up with nothing. But that’s the way this game goes – and it’s probably the only way that this kind of toolset that we need has any chance of happening at all. Oh well.)

I don’t have a clue where to start with ‘proper’ modern app-development – anything IOS or Android or OS-X or Windows or Unix or anything of that kind. I struggled for quite a while to make any sense of Objective-C: to me it seems to combine the worst of C with the worst of assembler, with the advantages or sense of neither. I likewise struggled for quite a while to make any sense of Eclipse, and failed.

In any case, I know that, even from the start, it needs to be multi-platform, or at least in some sense cross-platform, in order to demonstrate some of the key points about an ecosystem of toolsets.

To give somewhere to start, I’d settled on doing some kind of web-app that could also work as a offline-standalone. In other words, somewhere that either includes or perhaps even runs entirely on the HTML5 / Javascript / CSS caucus.

I’ve explored pretty intensively on frameworks and the like. For example, there are a few standalone oddities like TiddlyWiki – except, in that specific case, every darn save has to carry the entire wiki source-code with it, at minimum of 600+kb a shot; and since its CSS is embedded in its Javascript code, and its user-data embedded in the save HTML DOM,, there seems to be no way to make it satisfy some of the other key requirements, such as responsive-layout or cross-platform data-exchange.

Scouring Themeforest and suchlike, I’ve found a few frameworks and site-templates that might be usable as a base from which to start on the kind of app-development that seems to be needed for that prototype. Beyond that, there’s a bewildering array of Javascript-libraries and pre-process languages (CoffeeScript, LESS, Grunt, Brunch, etc, etc, etc) that I may need, but just don’t know. And choosing the wrong base-framework would guarantee having to scrap the whole lot and start again – which I don’t have the time or the energy to do – not any more, anyway. So I really do need to get it right first time, without fail, otherwise it’s not going to happen: I’m painfully aware of that.

I’m working on Macs (variously OS-X 10.8 and 10.9, if that detail is relevant).

I have various web-development IDEs here, installed, paid-for, working.

I also have various servers set up on my development machines: Apache, MySQL and Node.js, to name a few of the more obvious ones.

In that sense, I’m almost ready to go: I have enough basic knowledge, tools, frameworks, requirements-summaries and concept-sketches with which to make some kind of start. If you like, that’s hurdles 2, 3, 4, 5 and so on.

What I don’t have is the knowledge of how to get over the first hurdle: how to set up a compile-workflow.

When I last did web-development, there was a clear distinction between front-end and back-end: in my case, HTML, CSS and Javascript on the client-side, and PHP and MySQL on the server-side, all as distinct files, and all directly in their raw interpreted-language form. But that isn’t what happens now: instead, there seems to be an unavoidable requirement for some kind of automated-workflow via a make-tool such as Grunt or Brunch, to link together all of the various precompilers (Coffeescript, LESS, etc), libraries and dependencies (Twitter-Bootstrap, JSQuery, D3.js etc), minifiers and compressors (Uglify.js etc). And I don’t know how to set it up.

I haven’t found any information on how to do the very first steps: everything I’ve found so far assumes a full working-knowledge of the OS-X terminal and the Unix command-set and library-management Git and Subversion and the rest – which I don’t have.

And since I don’t have that knowledge, I’m stuck, at the first hurdle. Not at the second or third or fourth hurdle – I know how to deal with those. The first hurdle – and only the first hurdle.

So, here’s the request, again: can anyone show me, step by step, how to set up an appropriate automated workflow for web-app development, on Mac OS-X, that does not assume that I already know how to use Terminal or anything else of the non-GUI part of OS-X?

If all you’re going to offer is yet more ‘Just Do It’ platitudes… well, just don’t bother, okay? I’ve given seven years of my life helping others with step-by-step instructions on how to sort out their enterprise-architectures – almost all of it unpaid – so you darn well ought to understand why I can get a bit tetchy by this stage, if, when I do ask for help, all that I get back is yet more ‘Just Do It’ inanities. I’ve had more than enough of those pseudo-‘advice’ insults already, so please don’t be surprised if I tell you exactly where you can shove such them…

But if – unlike the ‘Just Do It’ crowd – you can tell me how to do that setup, then yes, that would be great: it would really help me a lot right now.

Or, even better, if you’re actually interested in taking on the challenge of the toolset-ecosystem, and do know what you’re doing in development and the like, then yes, I’d really like to hear from you. Again, I’m painfully aware that I’m not the right person to do this – but someone has to do this until the right person comes along.

Either way, please, please, let’s get beyond the ‘Just Do It’ bullshit, okay? This is a serious concern, and needs serious responses from serious people – not petty platitudes people pointless people who are only interested in playing around… At my time of life, I really cannot put up with timewasters any more. Sigh…

Over to you, if you would?

Tagged with: , ,
15 comments on “Getting beyond ‘Just Do It’
  1. Hi Tom,
    I confess that I am one of those “Just-Do-It-Ignorants”, but that approach works pretty well for me and does not leave the big picture aside. Something which is worth to blog about to explain further than just in small comments here, if I find the time or interest.

    With respect to GIT/Subversion/and such: I fear you lost the big picture and the sequence. First things first.

    Lets start with the assumption that the “process” is as following:
    Requirements > Architecture > Build > Test > Operate

    Source Code Management systems fall mainly in the category of build (while Eclipse for example covers the whole process if you want). What you need first is a defined development process, then the team with which you like to develop and then potentially a source code management system, if you know what branching strategy you want to apply.

    Given the fact of your description of the current status I can not see that there is any need to start in those details. To me it sounds a lot more as if you have to use a rapid prototyping approach, preferable with paying customers. So my advise stays the same, even though you discard it as “Just-Do-It” it carries a lot more than you have read out of it.

    I’ll be in London in Summer again and be happy to share a Pint or two with you and explain in detail and if needed also go into Subversion/Git details, but I doubt that you need it. Seriously doubt it.

    • Tom G says:

      Kai: “What you need first is a defined development process”

      Thanks, Kai, but did you notice that that’s what I asked for?

      I already know that I need one. I already know that, once I have a first-stage demo in place, I then need to find the right people. I already know that I’ll need a collaborative source-code management system (or something like that). I already know that. That’s the theory-part. I’m pretty good at the theory-part.

      What I’m not good at is this specific practice-part: not just the theory of how to get started, but actually getting started. And the one thing that I’m stuck on is this very first hurdle, on how to set up an automated web-app development-workflow, on Mac OS-X, and specifically a step-by-step set of instructions on how to set it up, that doesn’t assume that I’m already deeply familiar with Terminal and the command-line Unix interface. That’s all. Nothing else.

      For now, just that one requirement, step by step. Nothing else.

      Unfortunately, like just about everyone else here, you’ve given me lots of advice on just about everything that I don’t need to know (because I already know it, or even wrote about it over the past few years), yet none at all about the one thing that I’ve explicitly asked for above.

      So I’m still stuck, unable to move on, for lack of that one key piece of information.

      Frustrating as hell, to say the least…

      • Just as a side note: Based on my own experience as a developer I somewhat lack the understanding why you start the journey with a very specific idea about a very specific toolchain, be it that you have not shared why, be it that I do not understand it.

        From my perspective it looks as if you do not have a Development Chain and given the fact that it all looks as if you work alone it does not make much sense either. Therefore I put some time into setting up one of your desired chains (why, oh why, if an Excel Prototype could do the same)n and it works with the information provided on their websites. Due to that I assume that I got your hurdle wrong, because it was all too easy to setup (as claimed by these tool providers) and I managed to get a stupid hello world web application.

        So, please enlighten me that I can dig deeper to help you? What is the hurdle, because setting up grunt on node.js is a off-the-shelf installation and the hello world is just taking from the examples.

        • Tom G says:

          Thanks, Kai.

          The ‘first hurdle’ is simply that every one of those development-setup methods – including the Grunt.js example you kindly sent – assume a full knowledge of Terminal: in other words, the Unix command-line. Which I don’t have – and, to be blunt, of which I am arguably ridiculously-scared, but then I don’t have a spare machine that I can risk wrecking if I get it wrong. Hence why I asked for a GUI-based setup – preferably something that runs inside of some kind of all-encompassing visual IDE – rather than any of these things that runs only from the command-line.

          On why the particular tool-chain, there are various comments I need to give for additional explanation.

          Firstly, it’s not about any one specific toolchain: I did give Grunt and Brunch as examples, but I was also definitely explicit above that they were only examples, not mandatory requirements. (In fact someone else today pointed me to Meteor.js – https://www.meteor.com/main – which looks like it might actually work even better than Grunt or Brunch for the task I need. Except that it’s CLI-only again…)

          Second – and again, as I’ve explained many times – what I’m working towards is something that would mix a repository with both predefined and free-form graphics, and ultimately with audio, photo and probably video as well. The repository would have a (possibly?) completely-novel type of structure, based on collections-within-collections, as described in the metametamodel posts here. In that sense, Excel is way too limited for the task, even for a prototype; Evernote is closer for some of the functionality, but wouldn’t match up with the repository requirement.

          Third, reality is that I’ve been floundering with this for more than two or three years now, going round and round and round in circles trying to edge towards the real requirements – in other words, something that would give practical support for the way that EAs and the like actually work, providing a smooth bridge between free-form whiteboard all the way through to rigorous modelling, fully cross-platform, and consistent (though with necessary variations on UI, UX and capability) across the whole of the device-spectrum, from big-data system right down to handheld. It’s been clear for most of that time that a) it’s not going to happen unless someone builds some kind of prototype, and b) it looks like I’m the only person who’s in any way willing to do it, so it’s down to me, even though I’m very far from being the right person to build that it. In other words, I am facing up to ‘Just Do It’ – except I don’t know how to ‘Just Do It’.

          Fourth, what I’ve done so far is a) gather a huge range of requirements, experiences, notes and design-sketches – I do have a reasonable idea now of what a ‘Minimum Viable Product’ would need to do, and a provisional roadmap to take it on from there. And b) since one of the core requirements is for cross-platform, and another is for ability to operate standalone, I’ve spent a lot of time scouring places like Themeforest for something that I can use as a base – for example, site-template/web-app-template sets such as Developr or Pastel or Todo. Which all use the HTML5 / CSS / Javascript family, which in turn leads to the need for c), some means to do compile and make and minify and all the rest – (more than) preferably automated, and preferably not solely command-line. Which is where we started this post…

          Does that make any more sense now?

          • Quite some stuff to answer:

            1) Beeing scared about command line
            a) Don’t be scared
            b.1) Use a virtual machine to keep your system sane (see http://www.civicactions.com/node/1271 or many other posts) or
            b.2) Create another user and install node.js in user directory (not the most recent one, but one example (google for a better one): http://increaseyourgeek.wordpress.com/2010/08/18/install-node-js-without-using-sudo/) that way it cannot affect the system itself and when you drop the extra user you drop the installation.

            2) Toolchain
            Could HTML5 do the trick for your prototype? Assuming that you are willing to accept a tradeoff between perfect setup and speed I would vote that for protoyping you better try to go down the route of rapid prototyping, so tool simplicity is key. If HTML5 could do the trick you could just use a WYSIWYG HTML5 Editor and develop some prototypes including the willingness to refactor them later.

            3) Excel is not enough.
            Fair statement of yours. The only person who can judge that is anyways you. My own experience tells me that the majority of the standard IT solved problems can be solved with Excel or an Excel alike and just some need specific toolchains, even though the tool vendors try to tell us different.

            4) If it is just you do not put to much effort in setting up the right IT toolchain to do the work for you. Even if this is uncalled advice: the setup and maintenance costs do not pay back if the team is too small. So stay out as much as you are willing to stay out. The more the better. RoI here only lies in having a team or using it for a single person for education purposes (which would be fair again, but I haven’t read that requirement yet)

            5) Go for a WYSIWYG Editor for the moment which would allow you to kickstart the prototype and build something including the possibility to publish your application. Refactor later to some more solid development chain. Google is full of links for that. 🙂

            And yes it makes sense, but due to your description I even more doubt the need for grunt, brunch, meteor or similiar. Not yet, not now, potentially later.

  2. René Smulders says:

    Ha Tom,

    As Kai stated, take standard (tech) design process into account and add people, enterprise(client and supplier) and governance into your architectural design would be my advice.

    This approach works well for me for the big picture. Also take into account that you create “mickey mouse” visualisations, to explain this design to your stakeholders (on all levels, strategic, tactical and operational) -> different visualization explaining the same story….

    • If you can not explain it to a 4-year old you can’t explain it. Mickey Mouse Visualisations are indeed key. 🙂

    • Tom G says:

      Hi Rene – Yes, I know. I do already know that. It’s really good advice at the big-picture level, and I’m perhaps all too good at saying the same kind of thing myself… 🙁

      Unfortunately, what I need right now isn’t big-picture: it’s one specific small-picture detail, about how (not why) to set up an automated web-app development workflow on Mac OS-X. And right now I don’t need to explain this to any other stakeholder but me.

      The big-picture stuff comes later. The critique of what the app can or can’t do, or should or shouldn’t do, comes later. Right now I don’t have any demonstrator of any app at all for folks to critique, because I don’t know how to set up that development-workflow. That’s what I’m stuck on.

      I have no idea why people find it so hard to hear this – that their ‘advice’ is at completely the wrong level of detail – but I must admit it’s frustrating as hell that they don’t…

  3. Peter Bakker says:

    I still would go with TiddlyWiki:

    Running TiddlyWiki on Node.js brings several important benefits over and above the single file version:

    – You can edit your content on any suitably compatible HTML5 browser, including smartphones and tablets
    – Individual tiddlers are stored in separate files, which you can organise as you wish
    – The ability to build multiple wikis that blend different combinations of shared and unique content

    And I would use the Tiddlywiki data as input for D3 and start with something like this http://flowingdata.com/2012/08/02/how-to-make-an-interactive-network-visualization/

    But I’m not the right kind of guy to give advice because I do not know what I’m doing in development. I just hack scripts 🙂

    • Tom G says:

      Peter – many thanks for this: it’s not what I need, for the specific and explicit requirement stated above, but at least it’s at last some form of advice that’s even vaguely in the same ballpark…

      The explicit requirement above is for step-by-step instructions on how to set up an automated web-app development-workflow on Mac OS-X – and yes, I do have very good reasons why I want to do it that way. TiddlyWiki is a very nice approach, with a very nice architecture, and Jeremy Ruston is evidently very helpful, but it isn’t what’s needed here.

      To give some explanation of my competence, I’ve previously written a complete wiki-system, almost from scratch, though in the PHP/MySQL of around a decade ago, rather than the Javascript/Coffeescript etc of now. I do know what I’d need to do, in code terms, at least to a prototype / demonstrator level. All I’m stuck on is the very first hurdle, of how to set up a modern automated-workflow. That’s it.

      Tiddlywiki has some lovely ideas, some of which I probably do need to take up for this project. For example, its plug-in concept – plug-ins as just another form of ‘Tiddler’, essentially the same as text or graphic ‘Tiddlers’ – is exactly the idea we’d need for extensibility for ‘the app’. (I spent around a week or so delving into the innards of version 4, and some time exploring the structure of the current version 5, so I do have some reasonable understanding of how it works.) Yet there are several reasons why it’s probably not the right approach for what we’d need here:

      — Limitations for standalone: When coupled with Node.js, yes, each ‘Tiddler’ is a separate file. But in the browser, or in the IOS and Android apps, all of those Tiddlers are merged into one humungous file – usually a minimum of about 600kb – but which is also constrained by the limits of browser Local Storage – typically 5Mb per domain, I think? Per-Tiddler syncing back to the parent Node.js only occurs online; offline, where the browser allows it at all, every local saved-version is that humungous file – which is too unwieldy to be practical.

      — Limitations of content: Text alone is not going to be enough: even in the earliest versions, graphics are going to be essential. All we (seem to?) have at present with Tiddlywiki are those experiments with D3.js, which show ‘finished’ SVG graphics – not editable graphics, or any kind of freeform, both of which we will definitely need. Then add other core requirements, such as for photo-capture, audio-capture and probably video-capture too, and you’ll start to see the limitations that we’d face with trying to use Tiddlywiki as a core.

      — Limitations of data-granularity: This is probably the key problem for the suggestion of using Tiddlywiki as a core. The base granularity of Tiddlywiki is the ‘Tiddler’ – a discrete standalone document-level chunk of content, implemented as a distinct file/folder under Node.js, or, in the browser, a distinct parseable element in the HTML DOM. The base granularity we’re going to need for this requirement is the ‘mote’ – see post ‘EA metamodel – the big picture (and the small picture too)‘ – a significantly different type of data-entity, often many of them within the equivalent of a Tiddler, but sometimes encompassing more than one Tiddler.

      So yeah, I have already thought long and hard about this, for many years now. Without the app itself, it’s proving incredibly hard to explain what the app would actually do, and why, and why it would be valuable to enterprise-architects and many, many others. But to explain it, I first need to get over the hole-in-the-bucket problem of it not already being in existence. And the first hole I need to plug in that bucket – the biggest hole right now – is the lack of an automated web-app development workflow, so that I can get started on some kind of concept-demonstrator, so that I can then start to plug some of the other conceptual holes.

      Which is why, right now, I need practical advice, not on software-architectures, but setup of automated web-app development-workflow on Mac OS-X. Just that one item: nothing more than that. Please?

  4. I too am one of those “just do it” people. My thoughts were in your best interest and really did not mean to insult you. I’m talking from what has worked for me in hopes it can work for you.

    I’ve seen others wait and wait and wait until all the ducks (of understanding) are in the row before any action is taken. When many times, it is helpful to take any step and see … even if the first step picked (the “pick one”) is wrong, you get information to help you take a different or another step.

    Again, let me publicly apologize if my help was insulting. It was out of caring and did not mean to be insulting.

    • Tom G says:

      Pat – please, don’t worry! (And my apologies in return, too?) As I’ve said offline as well, no insult taken, and in any case I’m very aware that the advice was well-meant. It’s just that it isn’t/wasn’t what I need, and what I’d said I needed.

      I still don’t have the information that I need. Hence I’m still stuck at that first hurdle. Lots and lots of would-be advice about other concerns, but not about the one item that I actually and explicitly said (many times) that I need. Frustrating as hell, it really is… Is this how most people feel about enterprise-architecture as a whole? Sigh…

  5. Tom G says:

    Just as a general note: after much searching around, I think I’ve at last come across the kind of thing I need for the purposes I’d described above: a ‘build/make’ system for HTML/CSS/Javascript apps that doesn’t rely heavily on Terminal (as Brunch and Grunt both do).

    More precisely, I seem to have found two of them (though both of them are Mac-only):

    Hammer

    CodeKit

    Both of them compile CoffeeScript to Javascript (which is something I’d really wanted), and both compile LESS and/or SASS to CSS (which I also definitely need), with various other tweaks and goodies that look very useful, such as the ability to build upward from a template.

    They’re both designed primarily for static sites, which may be a bit of a limitation going forward, but at least it’s a start. So yeah, does look like I at last may have a way to get past Hurdle #1 – which I didn’t have before. Will no doubt take me a fair bit of time to get a reasonable way up the learning-curve, but watch this space, perhaps?

Leave a Reply

Your email address will not be published. Required fields are marked *

*