When deciding on what elements to include in a MOSS site definition, i.e. lists, libraries etc. is there a rule of thumb on how best to make this decision?
Would appreciate anyones suggestions.
All the best
This what I've done several times:
Copy one of the definition
existentes.
Modify this copy in the way I need,
deleting the list and all the other
stuff I don't really need.
Create features which will add
funcionality to the site.
Include these features in the site
template.
I think features (and solutions) are better than other things to add functionality on sites.
Related
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.
I recently found out that Scala is an absolutely interesting programming language.
Since I'm not a real desktop application developer but more a webdeveloper I wanted to try out the play framework and if it works well for my purposes.
So far, I really like it, it seems to be easy to use and the developers really think it through.
BUT
I wanted to create an application with different templates, like an "internal", "external" and "admin" area. I already figured out to try out the "modular application" thing which seems to work good but I can't see any possibility to create something like multiple "template" files..
After a few hours of googling, I thought I should just ask..
Has anybody of you done it yet? Any tips how to organise it the best way?
Thanks a lot!
You can have as many views as required and you can also organize them in packages (under the app.views package) in many levels. All you need is just to learn how to reference required view from the controller.
Take a look to this sample schema.
In other words the most importantis clear and comfortable for you order, which you will be able to work with after 3 years without additional notes.
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.
I do alot of bugfixing and implementing new features for several different customers. These customers all report their bugs, change requests and new feature request into our Trac system.
Sometimes these requests result in me creating some SQL change scripts, sometimes there are Excel documents or Access databases with testdata, Word documents from the customer and so on. Alot of files that are used to fix one ticket and then can be deletede when the ticket is closed.
I usualy do this by creating folders in the filesystem like this: /customerXX/TicketNNNNN and then just dumping everything in there.
How do you organize your workfiles? Have you found some fantastic tool to do this?
I would say for scripts or files that are related to a particular ticket, the best thing to do would be to attach the file to that ticket in your issue tracking software - almost all issue trackers that I've worked with will allow you to do this. That way, you can look back and a) see exactly what you did in case something goes wrong, or b) do exactly the same thing if the issue comes up again later. That's almost certainly the best place to keep files with extra info from the customer, too (or at least the first place most people will look).
For frequently re-used scripts that aren't specific to a particular ticket, I would create a scripts/ or bin/ directory in the associated project, and keep them in there.
I also have a small handful of useful files that I keep in src/misc/ off my home directory, with things like SQL queries to get readable "explain" output out of Oracle and such, that aren't specific to any particular project. The number of these is small enough that subdirectories aren't necessary, though - I suspect if you ended up with a large number of these files, many of them could/should be moved to specific projects or your issue tracking system.
JIRA has been quite helpful for this at my site. It supports issue tracking, file attachments,and you can easily customize and categorize your projects and issues.
I use Fogbugz and I add all file to the case. I believe that no matter what application you use, The important is to keep this files for future references. If your bug-tracking tool does not let you attach file then add the files to the version control.
We use CaWeb4 and find it very easy to use for our bug tracking.
i just want to know about the files and folder structure for a site which is a plugin oriented like wordpress or joomla.
my requirement is to develop a site and want to add more functions via plugin or something like features.
what i need is to just add and additional information or functional sessions like in wordpress
we can use All in one SEO packages it will bypass the title and some other information.
or some other features like Related articles are shown at the bottom of a particular article body.
aam talking about a structure of wordpress.
does any one have an Idea please share with me.
hope every one understood my qustion as well.
thank you.
I think there are many possible solutions.
It might depend on:
scalablity (how large do you want it to support plugins and do the reuse parts of each other?)
vibility (how should the plugin address become visible in the url?)
deployment (who can add new plugins? is it open for everyone or just certified developers)
You could go for:
www.domain.xyz/plugins/some_module/
But what if the plugins arent plugins but becomes default part of the system afterwards?
Then it would be more logical to call them what they are like:
www.domain.xyz/some_module/
But then you might get into problems with plugins name like exisiting system folders. Therefore you would need some "reserved" list of foldernames to prevent that.
You could also go for:
some_module.domain.xyz/
But that would requiere your webadmin or webserver to support multiple aliases for one website on the other hand, this arhictecture would bring scalability, because you could move the modules to other webhosts later on. But its also more expensive work in the development + its hard to make it "user/developer controlled" as this could grow.
You could have a look at how FaceBook is handling Applications too. Thats a plugin interface too. Slow, but implemented.