Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
I have had pretty good success (and some random failures) with this design. Alas I can not find a reference to it online, and more than likely the name I have for it is incorrect. I found the design when I was a younger child, the design was in a book of paper plane designs.
The design is fairly simple though:
- Start folding a traditional paper plane: http://en.wikipedia.org/wiki/Paper_plane using the example image on the wikipedia page, before performing the middle/centre step in the image, insert an additional step.
- The additional step is:Fold the tip down so that it touches the tail of the plane at the centre line, then fold it back up again so that an additional crease is made about 2cm from the one made just before.
- Continue with the instructions on the wikipedia page.
The result will be a traditional dart with a tiered nose, which will fly a bit more stabler than a traditional dart. You may need to gently tweak the trailing edge of the wings to create a bit more upward direction (lift is probably the wrong word). You can also play with the positioning of the creases made in the additional step to adjust the balance, which will probably achieve the same results as the wing tweaking.
The following SVG should give you a hint: http://pastebin.com/PnsaGPzK
I currently work for a medium sized business and we're going to replace a lot of in-house PHP systems with j2EE. Our small Dev team (of around 10 developers & team leaders) will require training for the shift since we only have a few hands who actually know java to any useful degree and I don't think anyone is well versed in j2EE. For the past two years our main language is PHP 5 and everyone is fairly clued-up and could write passable java, but we would all benefit from further up-skilling in this area. So I guess there are two main issues we need to look at: improvement writing java, and j2ee training.
I've been tasked to find suitable training for myself, which may be used later for the elevation of the team's skill-set. It's been over a decade since I undertook any formal training and, to be frank, (even though have done the obvious by searching through Google) I no longer feel I know, what I should be looking for when it comes to reputable schools/training facilities/courses.
There seem to be many questions I should be asking, such as: What are the key identifiers for a good training sources? What should I keep in mind when looking for these courses? Are online courses OK?
Has anyone out there in the slashdot community been in a similar situation? Do you have any good advice, to take on-board? Do you know of any courses that target the up-skilling of PHP developers to Java?"
Kevin Lacy, chief traffic engineer for the state DOT, and the one who filed a complaint with the N.C. Board of Examiners for Engineers and Surveyors, protested that in trying to have Computer Scientist David Cox investigated for his detailed complaint about a traffic intersection while not licensed as a professional engineer, "I'm not trying to hush him up."
It does my head in.
Anything that increases choice is a good thing.
I have been given the task to asses the feasibility of incorporating an off-the shelf, free content management system (budget constraints!) to essentially replace the static content and perhaps some of the dynamic content too. My manager has shortlisted a selection of CMS packages based what he perceived to be market leaders which includes: Drupal, Joomla! and WordPress. And our final selection of probables includes these three leasers and also eZpublish. My manager cites the source of this information as cmscritic.com.
Neither myself or my manager have a massive amount of experience with free CMS systems, however I have had to use Wordpress in the past; and from my little experience, doubts arise when thinking about having to maintain custom versions of these CMS packages. I'm also concerned about over/undershooting the mark so far as requirements go.
Our main motivations are to reduce the amount of changes in our weekly releases, and also to push content responsibility to the people who actually want the changes (and make the time consuming mistakes that our development team has to rush to fix). The system will have to integrate in to our current legacy PHP scripts, so there will probably need to be a mix of dynamic CMS pages along with our already dynamic "customer account" related pages.
I would like to know if there are any obvious choices we have failed to include in our short-list and if there is any slash-doters here that have fallen in to similar circumstances and can offer any sage advice?
We have already attempted to trim a little fat and our list of essential (must-have) features includes:
* Document Management (aka Versioning): The Cms maintains a version history and audit trail for all content.
* Content Virtualization (aka Sandbox): Content providers can view the final results of their changes without having to publish and without affecting other users who may also be making similar changes.
* Searchable Content Back-end: Content providers and administrators can search the content repository.
* Shopping Cart
* Support for small screen devices
* Meta-tag Support: Setting up page titles, descriptions & keyword tags is a user interface operation, not coding.
* Wysiwyg Content Editor: The integrated editor, if it exists, does not display mark-up tags.
* Rtf/.doc support (aka Word import): Content can be created/edited in Microsoft Word and imported into the Cms.
* Workflow/Event Messaging (aka Content Approval): Before an item of content can be published it must pass through a series of pre-defined steps. At each step the system will notify those responsible for progressing the work.
* Role-based permissioning (aka Granular Privileges): Content providers can be allocated roles (eg. author, reviewer, editor) and the functionality available to them is constrained by the role under which they have logged in.
* Browser-based Content Provider UI
* Browser-based Administration UI
* Expandability (aka plug-ins)
* Integrates with non-Cms applications i.e. a logical separation of Cms controlled files and those of other applications
* Ldap Integration
* Adherence to Web Standards
* Cheap (aka Open Source)
We also are looking specifically at LAMP infrastructure to save too much re-skilling of our development team (but we remain open minded)."