This is a copy from my thread in the Jekyll-Forums
Situation
At our company we go through the same phases for every project:
Design
Presentation
Development
Unfortunately we are so tightly bound by the sheer number of projects, that we haven't updated our frontend-workflow for years. We are still wandering the old road:
Design (Photoshop)
Presentation (convert psd to jpg Screenshots & Mockups)
Development (convert psd to html)
I always hate to see how much time and money we're leaving on the table by trodding along this path. Each step is completely seperated from the others. And... ah well, I guess I dont have to list all the disadvantages this approach comes with.
I'd like to change that and create a sophisticated & flexible frontend framework for us.
Goal
For this Jekyll seems just right, since its fast and there are some nice automated styleguide-solutions out there. (eg this one)
Overall this is the plan:
In this workflow I see the following advantages:
Very fast & flexible (almost no extra work)
Much better Output (live-prototype instead of screenshots)
Happy Developers (styleguide instead of huge psd file)
Better connection between Design, Presentation & Development
Problem
I can see everything coming together nicely, but I'm wondering how one would do this part:
You have a Master-Version of the Framework with every possible component in it.
To start working on a new project you create a fresh instance of it that only includes the components you need. Only those components will be part of the automated styleguide.
Of course I could just keep the Master-Framework somewhere, copy-paste it for each new project and delete the uneccessary componenty by hand. But I guess this is just asking for trouble.
Does anyone know a better solution for this?
Some kind of generator, that could do this?
Thanks for any kind of advice. :-)
This is a good question.
What you're trying to do is called atomic design, and this can be done with Jekyll.
By using includes, you can build a powerful set of components like :
{% include fish.html param1="truite" param2=page.variable %}
And you can then get datas inside included files with :
{{ include.param1 }}
or
{% if include.param2 %}
...
So, yes !, you can get out of this old fashioned design workflow with Jekyll.
Related
Anyone out there using LiveCode in a multi developer project?
Either way, can someone recommend a good source control system / plugin to use?
We've looked at MagicCarpet but since it is no longer developed we wish to use something else.
Thanks
I'm working on a solution to this problem by exporting the stack file as a structured directory of script, json and image files which will diff and merge nicely in most VCS. It is not yet available but the intention is it will be open source. My goal is to demonstrate it at the RunRevLive conference in May.
Here's the repo for lcVCS https://github.com/montegoulding/lcVCS
I have put a git library stack on revOnline (libVersionControl) that exports to structured xml files that git can handle. It works as far as it goes, but I have hopes that Monte's solution will supersede this effort.
revOnline link to stack
Yes, our team has been using LiveCode with multiple developers. Since the Livecode community is still young, acquiring good source control tools can be a challenge. Our solution has been to break code into modules (stack files). When there are updates to merge into the main codebase, we clone our existing codebase, and merge code changes manually using line by line compare in a text editor. This is not a fun process, but is much less painful than it sounds.
If I were to redesign the system, we would simply use Git (Github.com etc.). There is no reason this would not work with Livecode stacks.
We use LiveCode in a small team with Subversion.
We don't have a perfect solution, but it is very lightweight; we all use a custom extension to the standard toolbar, which among other things has a 'save+backup' button. When we started using it with Subversion, we added code to this button which saves an XML sidecar file for the stack. The file contains all the scripts, custom properties, and optionally fields (controlled by user property in each stack). In our case almost all of our work is in scripts, so this works for us.
The effect is that each time we commit to SVN, we're always committing two files, the LiveCode stack and the accompanying sidecar file - the latter works fine for diffing etc.
Where this lets us down is that we don't have any solution for merging. If we were working on larger systems more actively, we'd also modify I expect look to modify the sidecar format into a complete folder of files. For now however this makes the situation workable (and it takes no noticeable time to generate the sidecar file).
Happy to share code if that was useful.
I know of a tool thats being worked on that is going to really help in this regard. When he showed it to me it looked very functional already. But I'm not sure when he will share it with the community.
So the point is, its just a matter of time before people's stuff comes together to make a turn key solution for this.
I've got a (dirty) production installation of Simple Machines Forum (SMF 1.1.13). It was a clean install, once... about five years, twenty updates, and 40 mods ago. Not to mention the custom code that was patched directly into the code base. This started as a for-fun side project, and didn't have any code management practices at the get-go.
Now SMF 2 is (getting closer to) going live, and I want to upgrade. But without leaving the custom features behind.
Keep reading, this is a general software management question, not an SMF support question...
I'm trying to figure out the best way to port the custom features into the new code branch.
In some cases, the custom 1.1.x functionality will already exist in 2.0. Yay, no work for me!
In some cases, there will be mod packages versioned for 2.0, and I can just install them directly on a clean SMF 2 build. Yay, minimal work for me!
In some cases, the code port will be fairly straightforward between the two versions (e.g. a few small changes in queries or global variable construction). (I've ported a few features/mods back from 2.0 to 1.1.x, so I'm starting to get familiar with it.)
In some cases, I'm just going to have to redevelop the features mostly from scratch.
Those last two options are gonna be hard to manage.
Any suggestions on how to port a large number of changes from one branch to another?
When it's not my own in-house code, that is. Here's my initial plan:
Diff between a clean version of 1.1.x and my "dirty" production code
Map each line diff to a feature ("That code update is the custom tagging feature, gonna have to port it line by line, and that one over there is the gallery, I can probably install an updated mod.") This would be SOMUCHEASIER if there were a diff tool that generated a consolidated report, instead of having to go through scores of files one at a time. Google and SO searches didn't find a tool like that-- Is there one?
Install a clean 2.0 branch
Install the available updated mods
Roll up my sleeves and go through my diffs feature by feature (this? is why I need the consolidated diff report. It would be hell to do page by page.) and build them back in.
Any better ideas? (Pointers to release management info are welcome, though of course with the caveat that it's not actually my code so I have limited control.)
Otherwise? I fear my options are ditch the custom features (not really feasible) or stay on the old branch. Both suck. Help!
tl;dr: Point me to a diff tool that will do consolidated file-by-file diff reports for entire directories. And/or help me figure out an easier way to migrate my custom code.
Your plan is generally the most practical approach, although I would say that you're heading in the wrong direction by looking for code-level differences. With no version control over the project lifetime and with no concise record of applied changes, in examining differences at the code level you are looking for a level of detail that may not give you the information you need to apply the same changes to a new implementation.
Move away from thinking of code-level changes and consider application-level feature and behavioural changes. What features have your changes introduced? In what ways does your application now behave differently due to your changes?
You say that there have been many unversioned changes over a long period - you will fail to find all the changes no matter what tools you have at your disposal and you will still need to consider the feature and behavioural changes that exist to fully represent the same features and behaviours in any upgraded implementation.
You know your application well, you use it and you do appreciate the feature changes that you have introduced even if you may not realise this.
Install a vanilla 2.0 release
Apply all appropriate mods
Apply relevant styling
Use the new system, note the differences in behaviour and develop from this a set of required features
Your feature set does not need to be complete - don't stall at the stage of trying to figure out all required changes, this will take too long.
Apply features gathered from most recent feedback (ideally through revertable mods)
Note the differences in behaviour at develop from this a set of required features
Repeat
I would like to access a Redmine taskbase via a simple text based interface - wondering what the shortest path would be (minimum investment/development).
Right now, this boils down to 2 use cases/phases:
Import a batch of tasks into Redmine from simple, wiki-based, bulletted TODO list, ie. plain text content. This is more of a one-off task, so a quick and dirty solution would be fine.
Later, some smooth two-way synchrosation would be great.. E.g. edit loads of tasks via some friendly plain text (or XML) in an editor, or scripting where I could manipulate all of them with simple text processing; then synchronise with Redmine and commit them back.
Any ideas on the easiest way to achieve these?
I'd prefer an external solution (i.e not touching the server), especially for the one-off import case; something like a neat IDE/editor/client, or a standalone Ruby script (e.g using the RM API).
If an appropriate RM plugin would be available, I would not resist giving it a try (can get root access from our lovely IT support:)..
Current ideas:
Emacs/Org-mode, looks like a great combination of a cool task manager UI and full plain text power. It seems rich enough to capture tags, states as well. This artice looks promising Orgmode and Roundup: Bridging public bugtrackers and local tasklists, although not exactly a perfect match.
org-mode parser in Ruby, could be used in an script with redmine-api access, or - worst case(for me, right now)- in newly developed RM plugin.. This looks like a good start: org-ruby
export RM->XML, process file, import XML->RM... not sure if this is supported?
I guess it's always possible to talk to the DB directly, but I'd prefer to avoid that.
Actually, I'm also interested a similar solution for Bugzilla.
At the simplest level, you could write a RM/Rails plugin that parses an Org-Mode task list, updating corresponding issues in the RM Model.
Equally, you can build a view for Redmine (again as a Rails plugin) to generate an org list of the current (or subset of) issues.
For Bugzilla I think you would be best off using the XML-RPC interface to do your issue comparison/update sync, so you'd have to take a very different approach from Redmine.
If you have any specific questions, please update your question, it's quite broad at the moment.
Update
At the moment, there are a few plugins which will probably help you figure out your solution, for example Nick Boltons xml import and Martin Liu's Redmine CSV Import Plugin but neither of these are going to completely solve the problem for you, just give you some useful starting point.
On the other hand, If you write a script that interacts with Redmine's REST api, you don't need it to be in any specific lanugage, in fact you could do it in Emacs-lisp, if the target users of the script are all Emacs aware, then this might well be the best way to do the job. (it would certainly be the most appealing option to me.)
Maybe this can be useful: https://github.com/fukamachi/redmine-el
Given a project I'm about to start there will be documentation produced.
What is the best practice for this?
Should the documents live with the code and assets or should there be a separate documentation store?
Edit
I'd like a wiki but I will need to print the documents etc... It's a university project.
It really depends on your team. Where I work, we keep documentation in a wiki which is linked in with our team website. For the purposes of shipping documentation, the wiki can be exported and we run it through a parser that "fancifies" the look and feel of the documentation for customer purposes.
Storing the documentation with the code (typically in your source repository) is not a bad idea. Just make sure to keep them separated. For example, keep a docs folder which is on the same level with your src folder in your repository. This way, you can quickly ship the current documentation, you can easily track revisions, and anybody new to the project can immediately jump in without having to go to multiple locations for information.
Storing it in source control is fine.
This is an interesting question -- basically, what others are saying is right about generated documentation, source files and templates/etc. should be stored in source control and generated during your build process.
As far as requirements/specs/etc. documentation, I have worked both ways, and I very much prefer using SharePoint or a Wiki/document portal that is designed for document sharing/versioning. The reason is, most non-developer folks aren't comfortable working with source control systems, and you don't gain any of the advantages of intelligent merging if you are using a binary format like Word. Plus it's nice to have internet-based access so you can reference and work on the docs in a distributed team without people having to install extra software.
Here's a 2017 summary of the options and my experience:
(extreme 1) Completely external (e.g. a wiki, Google Docs, LaTeX, MS Word, MS Onedrive)
People aren't bothered about keeping it up to date (half of them don't even know where to find the page that needs updating since it's so out of the trenches).
wiki platforms are “captive user interfaces” - your data gets stored in their proprietary schemas and is not easy to examine with a simple text editor (Confluence is even worse in that you have no access to the plaintext content at all anymore)
(extreme 2) Completely internal (e.g. javadoc)
pollutes the source code, and is usually too low level to be of any use. Well-written source code is still the best form of low level documentation.
However, I feel package-info.java files are underutilized.
(balance) Colocated documentation (e.g. README.md)
A good half way solution, with the benefits of version control. If a single README.md file is not enough, consider a doc/ folder. The only drawback of this I've seen is whether to source control helpful graphics (e.g. png files) and risk bloating the repo.
One interesting way to avoid this problem is to use plaintext diagram tools (I find Grapheasy and Text Diagram to be a breath of fresh air).
plaintext can be easily read even if your rendering engine changes as the years go by.
Github's success is in no small part thanks to its README.md located in the root of the project.
One tiny disadvantage of this approach though is that your continuous integration system will trigger a new build each time you make edits to the README.md file.
If you are writing versioned user documentation associated with each release of the product, then it makes sense to put the documentation in source control along with its associated product release.
If you are writing internal developer documentation, use automated internal source code documentation (javadoc, doxygen, .net annotations, etc) for source level documentation and a project wiki for design level documentation.
I think most of us in the industry are not really following best-practices and it of course also depends a lot on your situation.
In an agile environment where you would have a very iterative process of release, you will want to "travel light". In this particular case, Jason's suggestion of a separate Wiki really works great.
In a water-fall/big bang model, you will have a better opportunity to have a decent documentation update with each new release. Also you will need to clearly document what version of the requirements was agreed on and have loads of documentation for every tiny change you do to requirements (due to the effects it has on subsequent stages). Often if the documentation can live together with the version controlled source code it is the best.
Are you using any sort of auto-documentation or is it completely manual? Assuming that you are using an auto-documentation system, the documentation is more or less generated on the fly, and would be part of the code itself.
To me, (assuming that it's possible with whatever code you are using), this would be the preferred method of handling it, as you wouldn't need to maintain the documentation source at all.
In the past I've done web application development using Visual Studio. Initially I'd use the design view, editing the page visually. But over time I learned more and more (X)HTML, CSS, and Javascript. I became familiar with the tags for ASP.NET server controls and their common attributes.
I got to the point where I'd do all the markup by hand (still in Visual Studio though) and then test the site in an actual browser. Of course I'd also still use Visual Studio for programming server side functionality in C#, but never the WYSIWYG page editor. I was able to get work done faster too, getting the site to look just the way I wanted, and the same across different browsers.
Now I'm going to be taking charge of a public facing website (entirely static content - no ASP.NET, PHP, or anything). The website was created and maintained using Dreamweaver, which I don't have and never used before.
I'll be working from home, so the organization is looking into getting me a copy of Dreamweaver. Even though it's not money out of my own pocket ...
Is it worth using Dreamweaver if I probably won't touch the visual editor?
Or should I tell them to save their money and I'll just use Notepad++.
Or am I crazy and should relearn to use a WYSIWYG editor?
I do 95% of my web dev stuff using Dreamweaver's code editor. But, for the other 5%, the WYSIWYG stuff really comes in handy.
Plus, it's not your money anyway. I'd say get it and if the WYSIWYG stuff is too much for you just keep it in source code mode and use it as an editor.
You may not know until you see the code. If they were using things like Dreamweaver templates, unless you are going to extricate them, you may end up needing Dreamweaver for sanity sake.
Dreamweaver is really useful if you maintain a site with templates. If the site is in PHP or ASP, then all you need to do is put the common parts (header, footer etc.) in a separate file and include them in the different pages. If the pages are static then the common parts can't be included. Which means that if you want to change the menu, you have to change it in all pages. With dreamweaver, you can save a page as a template and when you create a new page from a template, dreamweaver stores it in the comments. Next time you update the template, all the pages that use the template are updated. I found this to be the best use of dreamweaver.
I haven't used a WYSIWYG HTML editor in years, all the HTML I produce these days is hand-coded, and it's something I would recommend to anyone. WYSIWYG Editors simply make it far too easy to throw in tons of unnecessary markup, and then you end up with unwieldy pages that are tricky to work with and hard to fix browser compatibility problems in.
However. If you're taking over a large existing codebase that has been produced this way, I'd say you probably want to make sure you at least have access to Dreamweaver or a similar editor (if they were produced in Dreamweaver, that's probably the best choice). Simply because many pages designed in this way are rather verbose, and can be a nightmare to deal with in a text editor.
This depends - you mean old school Dreamweaver or CS4 Dreamweaver?
With all the new additions (code hinting with some of the newer javascript frameworks, a "preview" that is integrated with webkit so you can see your page in action, being able to test AJAX calls and do a "code freeze") I'm tempted to walk away from jedit and try it out.
I believe that DreamWeaver gives you intellisense in the code editor for HTML, so I would use it for that, if you're not paying for it. I wouldn't pay for that myself though :)
If the Visual Studio editor works fine for you, there is no point in switching.
And if you don't like WYSIWIG editing, then there's no point in learning it. I stopped using WYSIWIG years ago, and like you, I've found it to be much more flexible and reliable to edit HTML/CSS by hand.
If you like DreamWeaver more and the organisation is willing to pay for it, then go for it!
FWIW, I do a lot of HTML and javascript coding in dreamweaver's code view- the JSF extensions are nice as well. I got it as part of the CS3 bundle, since I needed to get my hands on photoshop and illustrator as well to carve up graphics. If possible, try to get your company to get the whole bundle, since graphics manipulation is always important when you're maintaining a site- and most designers will be giving you photoshop source files. I never ever go in wysiwyg mode, and it's still useful.
I use dreamweaver, but not for the same reasons as everyone here seem to. I like the syntax highlighting, and I absolutely LOVE the way Dreamweaver handles FTP in the window on the right. If I could find another editor that would offer these two things, I would, but none seem to be that great.
I code my pages by hand usually (I do a LOT of PHP, which dreamweaver 8 obviously can't preview) so I do a lot of things like (1) edit page (2) upload changes (3) preview live on testing server. However, I still use the WYSIWIG editor occasionally, especially if I need to throw something together using tables or form elements. I just find it to be a bit quicker that way than doing things by hand.
That said, I never use Dreamweaver (8, mind) for CSS, as the implementation is buggy at best. I much prefer to do CSS and more complex HTML by hand. I also do not use the standard method of templating, as I prefer to have one "index.php" that calls in the appropriate template and stuffs data into it that it generated before.
All that said though, Dreamweaver offers a nice enough set of tools that I don't really want to leave it, and it certainly won't hurt to learn it, especially if its free. I'd say at least try it out and see if its going to work before making a final decision. It comes down to what you personally prefer to use.
I hand-code but there are times Dreamweaver is incredibly useful:
Making visual-tweaks to someone else's complex HTML. It's much quicker to use the WYSIWYG if you're short on time and the code is a mess.
Dreamweaver has got an incredibly good search and replace. The tag-based searching is the best I've seen anywhere for you whilst the regex seach/replace allows back-references, named groups in the replace field etc.
The code Dreamweaver produces isn't too horrific and it's fairly good at not breaking your own nice code if you ever dip into the visual editor.
I use dreamweaver CS5 for code only on a daily basis, and it's a great tool. It is very effective, and its a great tool even for people who already know how to write code. Some of its' features that make it one of the best editors, in my opinion, are:
Code coloring
Customizable color-schemes
Error highlighting
in-app validation
Autocomplete & Codehinting (works great!)
in-app FTP
New document type dialog (great for quick start)
Search & replace
Code Snippets
There are many more features, like setting up a local server and binding it to a database so you can write queries more easily and use dreamweaver's "help" with server-side code, but I haven't really got into it.
Bottom line:
If you are considering getting Dreamweaver mostly for code editing, then I'd say it's definitely a great deal - even if you aren't going to use some of its' other features.
Dreamweaver's a tad bloated for something which you really can just do in Notepad (++ or otherwise). No WYSIWYG will give you code to the same quality as hand-crafted code. Especially since it's vanilla HTML, just use an everyday programmer's text editor. Having intellisense isn't that important: I mean, there's only about 10 tags you need to know.