Posts Mentioning RSS Toggle Comment Threads | Keyboard Shortcuts

  • Mike 9:48 pm on March 31, 2008 Permalink | Reply  

    SEO Analytics 

    Our first major undertaking is our SEO Analytics software. We’ve been prototyping and designing scalability into the software for a while now and thought it was time to talk about it.

    Our goals for this software are to provide the end user with visual representations of the position of their domain across many search engine providers in an easy-to-read format. We are also using this as an opportunity broaden our experience in designing scalable software. So far, we think we have designed a pretty scalable suite of software and software components. We hope to share more on that later.

    For now, here are some screens that are under development.

    • index
    • signin
    • keywords
    • navigation
    • questions

    Features under development include SEO campaign tracking, RSS feeds, shared accounts among team members, competitor tracking, report exports, and widgets. We are already using some of the features to track our own domains. You can try out some of the underlying services today.

    We even want to open up our keyword position locating services as web services for the world to use as we finalize the development and testing in those areas. You can subscribe to the 72 Miles RSS feed to keep up to date on this product and our open source project, Architecture Rules.

     

  • Mike 1:54 pm on March 22, 2008 Permalink | Reply
    Tags:   

    architecture-rules-2.1.0 on the Horizon 

    Architecture Rules has been progressing. After 5 releases under 2.0.x, we have a tentative road map for the next release, slated to to hold the 2.1.0 tag. Here are some of the upcoming features you can look for.

    Maven Plugin

    Mykola has been working hard on the maven-architecture-rules-plugin. With it, you will no longer even need to write a unit test. Just write your architecture-rules.xml, and attach the appropriate goal to Maven’s test phase. He has been tackling multi project projects recently. This is sure to make asserting your architecture even easier for Maven users.

    Maven repository

    Speaking of Maven users, development of Architecture Rules relies on Maven. Today, to use Architecture Rules, you’d have to download the Architecture Rules jar and put it on your own repository, or your lib directory. This is too much work and we shouldn’t expect you to have to do that. We are going to get the jars and sources up into a Google Code hosted repository so you can just declare the dependency and repository in your pom.xml and get started even faster. In fact, we already have it up, its just not documented yet. Here is the first public mention of it.

    Just add this repository:

    <repository>
<id>architect-rules-repo</id>
<name>architecture-rules repository</name>
<layout>default</layout>
<url>http://architecturerules.googlecode.com/svn/maven2</url>
<releases>
<checksumPolicy>ignore</checksumPolicy>
</releases>
<snapshots>
<checksumPolicy>ignore</checksumPolicy>
</snapshots>
</repository>

    And this dependency:

    <groupId>com.seventytwomiles</groupId>
<artifactId>architecture-rules</artifactId>
<version>2.0.3</version>

    Java 5

    We think its pretty safe to assume our users are up to Java 5 now, so we are going to update the code base to Java 5. This also makes it easier for us to integrate the maven-architecture-rules-plugin. If you are not up to Java 5, the greatest version you will be able to use is 2.0.3, which is a good release and should do the trick for you.

    Configuration Chaining

    Finally, rather trivial in the whole scheme of things, but if you opted to use the programmatic configuration over the recommended XML configuraiton, then we’re going to slightly modify the Configuration class to allow for chaining. So instead of:

    Configuration configuration = new Configuration();
configuration.addRule(rule1);
configuration.addRule(rule2);
configuration.addRule(rule3);

    You can use:

    Configuration configuration
= new Configuration()
.addRule(rule1)
.addRule(rule2)
.addRule(rule3);

    This is going to be great once you see an example where you add all of your rules, add all the package locations, and set up the other options.

    So thats what we have been working on at Architecture Rules

     

  • Mike 3:43 pm on March 1, 2008 Permalink | Reply  

    Software Engineering Goals 

    I talk a lot, in conversation, about the software engineering goals. I don’t know who officially defined these as the goals of software engineering, but this is what the mountains of documentation that I was required to read and be tested on in the branch of the military that I served in defined as the “Software Engineering Goals.” So, since these have stuck with me over the past many years, and because I talk about them, and want to relate them to my previous post I thought now would be a good time to introduce them.

    They are, modifiability, understandability, reliability, and efficiency.

    Modifiability

    Modifiability is the hardest goal to attain, and it’s even harder to measure. Modifiability is controlled change to the software in which some parts are altered without increasing the complexity or obscuring the logic that has already been established. There are two reasons you might have to modify programs: to change the system due to a change in the original specifications or to correct an error made earlier in the development.

    Whenever you’re involved in designing a software system, you must try to structure it so that the logic is clear and consistent. Then, software can be modified effectively without increasing the intricacy of the original structure. As a maintainer, or one who is modifying the code, it is important that you follow the rules that have been established, and strive for consistency among that code base, even if the style that the code is in, is not your own.

    Understandability

    Understandable code is crucial in managing complex systems. Software that’s easily understood acts like a bridge between the problem and its solution. Understandability depends on the programming language: one that uses “English-like” constructs and control structures is more readable, making it easier to express design concepts.

    Understandability can also depend on things like design patterns, and a well defined domain. Understandability could also be minor things, like using a variable i vs index, or id vs userId.

    Reliability

    Reliability is critical for any software system that must operate for long periods without human intervention. Reliability is important in any software that is expected to be available 24×7, such as your typical public web application, or atypical nuclear power plant where the cost of failure is too great to allow anything less than the highest reliability possible.

    Efficiency

    The software system is efficient when it operates using available resources optimally. Resources can be divided into time resources and space resources. If the system must respond to real events, efficient use of time resources becomes critical. If space resources are important, such as in an automobile, efficiency of space resources can become more critical. You should use your judgment to select which resource to accompany each individual application.

    So there they are. I, and we are 72 Miles write web applications, typically with Java, so, given the nature of web development, I focus on Modifiability and Understandability, followed closely by Reliability. Efficiency isn’t always a huge concern, until an issue comes up.

    Here is an extended list of goals, that I frequently lookup.

    So how can you use Software Engineering Goals to help make the ‘better’ decision? Thats the next post…

     

    • rooloucouro 9:12 pm on December 19, 2008 Permalink

      good resource, please continue

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
esc
cancel