A few years ago, I created two Java wrappers for W3C validators: (HTML and CSS). Both wrappers seemed to be working fine and were even listed by W3C on their website in the API section. Until recently, these wrappers have always been part of ReXSL library.
A few days ago, though, I took the wrappers out of ReXSL and published them as a standalone library—jcabi-w3c. Consequently, now seems to be a good time to write a few words about them.
Below is an example that demonstrates how you can validate an HTML document against W3C compliance rules:
Hamcrest is my favorite instrument in unit testing. It replaces the JUnit procedural assertions of org.junit.Assert with an object-oriented mechanism. However, I will discuss that subject in more detail sometime later.
Now, though, I want to demonstrate a new library published today on GitHub and Maven Central: jcabi-matchers. jcabi-matchers is a collection of Hamcrest matchers to make XPath assertions in XML and XHTML documents.
Let's say, for instance, a class that is undergoing testing produces an XML that needs to contain a single <message> element with the content "hello, world!"
This page contains most typical mistakes I see in the Java code of people working with me. Static analysis (we're using qulice can't catch all of the mistakes for obvious reasons, and that's why I decided to list them all here.
In XDSD projects we specify requirements using Requs, a controlled natural language that sounds like English, while at the same time is parseable by computers. A simple requirements document in Requs may look similar to:
This Software Requirements Specification (SRS) defines two types (Department and Employee) and one method UC (aka "use case").
Unlike with many other modern languages, parsing XML in Java requires more than one line of code. XML traversing using XPath takes even more code, and I find this is unfair and annoying.
I'm a big fan of XML and use it it in almost every Java application. Some time ago, I decided to put all of that XML-to-DOM parsing code into a small library—jcabi-xml.
Put simply, the library is a convenient wrapper for JDK-native DOM manipulations. That's why it is small and dependency-free. With the following example, you can see just how simple XML parsing can be:
When using the hosting, you need to change the CNAME record in your DNS so that it points to www.example.com.aws.amazon.com. After changing the DNS entry, your static website is available at www.example.com just as it would be normally.
When using Amazon S3, though, it is not possible to protect your website because the content is purely static. This means you can't have a login page on the front end. With the service, you can either make your objects either absolutely public—so that anyone can see them online—or assign access rights to them—but only for users connected through RESTful API.
In XDSD, everyone—including project managers, analysts, programmers, and product owners—receives payments based on deliverables with agreed upon budgets. In the fhe first section of the article, How XDSD Is Different I explain exactly how this concept works. I don't explain in the article, though, how we decide which hourly rate is acceptable for each project participant.
When new people come to us, usually they have some numbers in mind. They know how much they expect to make per week, per month or per day. We rarely negotiate the payment rates, but rather just accept reasonable offers (see How Much Do You Cost?). Nonetheless, every few months, we review payments rates and change them accordingly (increasing or decreasing them as appropriate).
Further along in the article, is a list of factors that influence our decision making process regarding payment rates. However, before we get to the factors that influence our rate-setting decisions, it is important to mention that—unlike most other companies or software teams—we don't pay attention to the following:
This client ships in the jcabi-http Maven artifact. However, the client part is not the only benefit of using jcabi-http. Jcabi also includes a server component that can help you in unit and integration testing of your HTTP clients.
eXtremely Distributed Software Development, or XDSD for short, is a methodology that differs significantly from working in traditional software development teams. Most XDSD methods are so different (yet critical) that many newcomers get confused. This article should help you bootstrap once you join a project managed with by XDSD principles—either as a developer or a project sponsor.
This manual explains the workflow used when working with a XDSD project hosted on GitHub.com. You start when a GitHub issue is assigned to you. Next, you will receive a message from a project manager containing the issue number, title, description and its budget in hours (usually 30 minutes).
If you don't agree with the budget allotment, don't hesitate to ask for an increase. As soon as you are comfortable with the budget and understand the scope of the work, say so in a reply to the ticket and start working. Be aware that you won't be paid for time spent above and beyond the allotted time budget.