Guyub adalah perusahaan TI berpusat di Palembang dengan fokus pada F/OSS Produk-produk >> Layanan-layanan >>
Aug 07, 2010
Name: simple Organization: localhost Version [1.0]: Scala version [2.7.7]: 2.8.0 sbt version [0.7.4]:
??def main(args: Array[String]) { ????println(“Hello!”) ??} }
Jul 14, 2010
One of the great things about Eclipse is that?unlike the celestial event and the unfortunately-named movie?everybody gets to see it; regardless of your location on earth, you have access to Eclipse. But, like Linus, some people are confused as to the nature of Eclipse. To try and help people better understand Eclipse, I?ve created a ?What is Eclipse?? talk that takes an audience step-by-step from what is commonly understood through a voyage of discovery of the true greatness of Eclipse. More specifically, I start by introducing Eclipse as a Java IDE. This is generally easy for the sorts of audiences that I speak with to understand: folks in the software industry understand IDEs (though there are still a few emacs hermits out there; and I mean ?hermit? in a wholly-endearing way). I spend the next couple of slides broadening the technical horizon by introducing Eclipse as a platform for building IDEs, tools, desktop applications, server applications and runtimes, and more. All this technology is wonderful. But technology is only part of the Eclipse not-so-secret sauce. All of that technology comes from the many open source projects at Eclipse. We have a lot of projects at Eclipse. A lot of projects. Up to this point in the presentation, most of the discussion has been around just a small handful of projects. The ?Eclipse? Project is responsible for creating most of what people think of when they think of Eclipse. Specifically, the Eclipse Project creates what we try very hard to consistently refer to as the ?Eclipse SDK? (that is, a software development kit for building Eclipse-based applications). The Eclipse Project leverages the work of several other projects (Equinox comes immediately to mind) to provide important bits of information, but most of the bits that people think of when they think ?Eclipse is a Java IDE? comes from the Eclipse Project. Now this is where things start to get a little weird. The Eclipse Project is what we call a ?Top-Level Project?. It is?effectively?a container for several smaller-scale projects. Each of these smaller scale projects, often referred to as simply ?projects? or ?subprojects?) is a distinct entity that contributes parts to the greater whole. The Platform Project, for example, produces the UI, workbench, and many other fundamental services and frameworks; the Java development tools (JDT) project produces the Java compiler, editors, debugger, and such; the Plugin-Development Environment (PDE) produces tools to aid in the construction of plug-ins; and more. All these Projects have distinct development teams, web sites, and other resources. The Eclipse Project is just one of the top-level projects at Eclipse. There are currently twelve top-level projects that organize dozens of projects. Top-level projects provide more than simple organization of projects. Each top-level project has a ?Project Management Committee? (PMC) that is responsible for providing oversight and guidance to the projects in their care. Each top-level project is a little different from the others, reflecting different values and technical areas. Some top-level projects tightly organize their projects; others allow greater levels of flexibility. The fact of the matter is that we have a heck of a lot of projects at Eclipse. At last count we had more than 250 projects (I can hear you gasp at that number). The project is the finest-grained organizational unit at Eclipse. Each project has its own group of developers (called ?committers?), its own website, forums, mailing lists, source code repositories, downloads and more. Some projects provide aggregations of other projects; a project can, for example, have subprojects of its own. It?s left to the project teams to decide how they want to organize. Typically, mid-level projects tend to be used to provide some hierarchical organization for related projects. Very often mid-level projects (and top-level projects in some cases) provide handy aggregate builds and downloads of the software produced by the projects they contain. The Web Tools Platform Project, much like the Eclipse Project, is a good example of this. Web Tools contains multiple separate projects (e.g. Dali and EJB Tools), but distributes downloads and updates under the top-level project. As an outsider-looking-in, Web Tools comes across as a single source of software (the fact that it is really multiple projects under the covers is a bit of an implementation detail). So anyway? we have a lot of projects. They?re organized under top-level projects that provide oversight and guidance. Chances are very good that we have something going on at Eclipse that interests you. But Eclipse is more than just technology and projects. Eclipse is? a Community.
Apr 08, 2010
EllisLab is blessed with two of the greatest communities that can be found anywhere on the internet in ExpressionEngine and more recently CodeIgniter. Despite being a relative newcomer to the scene, the people attracted to CodeIgniter are among the smartest, most talented and down-to-earth developers around today. From time to time we want to highlight some of these talented people, and we’ve asked them to lend their voice to ours. Have your voice. I hope you enjoy what they have to say as much as I did. This week, our Community Voice author is Bruce Alderson, known on the forums as madmaxx, who has written a wonderful guide on how he uses subversion with CodeIgniter. Bruce is an elder web monkey and systems programmer. He totally digs the craft of building software, making cool stuff, and causing people to laugh so hard liquids are forced from their nose. He’s currently the Chief Monkey at Discovery Software and author of the not-at-all famous robotpony.ca. (Go read the one about shaving your yak) After working with CodeIgniter for a few months (and WordPress for a few years), I?ve settled on a way to set up web projects that works well for development, deployment, and source control. Note that this style of layout only works on systems like Mac and Linux that have useful symlinks. The layout favours a vhost setup, and splits your code and resources out of the CodeIgniter sources. Splitting your stuff from the CodeIgniter stuff lets you link your Subversion repository to theirs, so that you can keep it in sync with their development. You now have a CodeIgnitor project ready for development. You can keep up-to-date with CodeIgniter updates, deploy easily, and get at your code without wading through extra levels of hierarchy.
First, the folder layout
some-domain.com/
app/
config/
controllers/
(etc)
public/
.htaccess -> ../site-extras/.htaccess
favicon.ico -> ../site-extras/favicon.ico
js/ -> ../site-extras/js
images/ -> ../site-extras/images
system/
application/ -> ../../app/
site-extras/
js/
images/
.htaccess
How it’s done
Jan 04, 2010
In software development, it?s crucial to track bugs and new features, and to be able to know exactly where a project is at any given moment. Bug tracking is crucial tot his goal; it allows a project manager to know what has been finished and what still must be done, as well as to outline to each developer their goals and responsibilities. Most developers agree on the importance of bug tracking. Here are five tips I use when utilizing bug tracking. Institute bug tracking for the development team, even if management won?t. There are lots of open source bug tracking packages that are free and easy to use. They can be set up on any server, and usually don?t require special setups. Create bugs if other teams won?t. It?s tempting to struggle against other teams to convince them to use the bug tracking system. This will almost always fail. Instead, it?s often easier to institute a policy amongst the development team to convert service requests into tickets yourself. As a team you may also consider filing the tickets with the requester as the person watching the ticket. After a few closed tickets, other teams may see the value and begin filing tickets. Track every bug, big and small. Joel Spolsky does a fabulous job explaining how remembering bugs gets more difficult as time goes on. However, the value of the documentation created by bug tracking is often overlooked. When bugs are filed, and fixed, and time goes on, it?s easy to generate statistics on who creates, who fixes, and what fixes are applied in the code base. New bugs can be linked to old bugs (to see regressions), and all the problems that have ever been solved are in one place. For this, it is crucial that whatever bug system you use has awesome search capabilities. It?s also important that developers write detailed notes on their solutions, or link to repository commits so that other developers can see the changes made. Track bugs and features together. Having both bugs and features in the same place means that the project manager as well as the developers can see the tasks on hand, as well as determine what should be pushed into the next release. Often times when considering a new release, project managers only consider new features, because they don?t see the amount of work that must be done to fix the bugs. Having them together will help ensure that this doesn?t happen. Fix old bugs before starting on new features.
Occasionally I?ve been on a team where the management team doesn?t understand the point of bug tracking. However, upper management need not understand in order for the tracking to be effective. Bug tracking is, for the most part, a developer?s tool, to track errors, add features, and improve the development process.
It?s possible that other teams may also not understand the purpose or value of bug tracking, and will refuse to file bugs in the system. This is especially prevalent if the upper management team doesn?t support bug tracking.
There are two reasons why you want to track each and every issue in a bug tracking database: first, because it?s impossible to hold all the information in your head, and second, because it creates some very good documentation of the project over time.
While it?s known as a ?bug database? it should really be an ?issue database? because it should record everything, bugs and features together. Why? Because it makes it easier to know what work is on the table before getting started on a particular project.
The link to Joel?s post above outlines some of the benefits of starting on bugs before working on new features. I won?t rehash his points; what I will add is this: fixing old bugs first is crucial because developers hate doing it. Developers like working on new code. Developers hate going back and working on old code that they?ve already written, or that other people have written. By forcing developers to fix outstanding bugs before they work on the ?latest and greatest? new features means that the bugs will actually get fixed, rather than being pushed off and pushed off until they?re all that?s left before shipping the product.
