const_cast operators

If you want an expression to being const, just use the const_cast operator. For example if a legacy function written in C requires of a const argument, just pass a non-const argument by using the const_cast operator:

extern "C" {
    void my_function(const char *p);
};

std::string s = std::string("hello world");
my_function(const_cast<char *>(s.c_str()));

static_cast operator

The static_cast operator performs the conversion unconditionally, without verifying data types at compile time. This makes this operator quite dangerous, so, you need to verify data types before you use variables in this kind of type casting.

if (typeid(*ptr_a) == typeid(MyClass)) {
    ptr_b = static_cast<MyClass>(ptr_a);
    ptr_b->applySomeMethod();
}

You can use the typeid C++ builtin to verify the data type. Also, you must consider that this operator is valid only if the conversion is explicit. Suppose Parent is a base class to Child and that Unrelated is an unrelated class. Then conversions from Child to Parent are valid, but a conversion from Child to Unrelated is disallowed:

Parent a;
Child b;
Parent *a_1 = static_cast<Parent *>(&b); // valid upcast
Unrelated *c_1 = static_cast<Unrelated *>(&b_1); // invalid, Unrelated

The best usage for the static_cast opertaor, are numerical conversions, so you can cast from int, double, float and others of similar type to another int, double, float and similar types, including enum types. Some compilers does this kind of conversion explicit, but more strict compilers usually throw the proper warning on this kinds of assignment, without the proper type casting operation (line 4).

float a;
int b;
a = static_cast<float>(b);
a = b;

dynamic_cast operator

The dynamic_cast operator, among other things, does a runtime check over types applied on the cast operation. As the above example of static_cast operator, dynamic cast does the typeid() checking. Then, if you have a pointer or reference to an object whose declared type is a base class, but you need to obtain a derived class pointer or reference, you should use dynamic_cast, since the dynamic_cast operator is another RTTI (Run-time type information) operator. The use of dynamic_cast derives into more overhead of your program, so you must use it with moderation.

if (ptr_b == static_cast<MyClass>(ptr_a);) {
    ptr_b->applySomeMethod();
}

If the type checking and conversion fails, the operator returns a non-null reference, else it will return a null reference (zero). Also, some compilers will advice on the proper usage of the dynamic_cast operator, the more strict ones, will throw an error.

Parent a;
Child b;
Parent *a_1 = dynamic_cast<Parent *>(&b); // valid upcast
Unrelated *c_1 = dynamic_cast<Unrelated *>(&b_1); // invalid, returns NULL

reinterpret_cast operator

This — possibly — is the most risky to use type casting operator. It completely transforms a pointer to very different types. For example:

some_struct_s {
    short a;
    short b;
};
typedef struct some_struct_s some_struct_t;
some_struct_t *s;
unsigned long v = 0xd34db33f;
s = reinterpret_cast<some_struct_t *>(&v);
std::cout << s->a; // display first 2 bytes of value

As the example above, the pointer was completely transformed to different kind, with the dangerous assumption that the platform has a byte alignment that make possible to access the first to bytes of some address using this kind of operation. This cast is not portable, some compilers should throw some error about it.

The fact is that the reinterpret_cast operator overrides the initial declaration of the given variable, and makes possible to that variable to being reinterpreted as a different one. The usage of the reinterpret_cast must be done careful, for example for derived to base class reinterpretation.

BaseClass a;
DerivedClass *c = reinterpret_cast<DerivedClass *>(&a);

Since many of this kind of conversions are not possible in all compilers, you must try to setup your compiler to the most pedantic flags that it can allow. For example on GCC, you should use -Wall -Wextra -Wshadow -pedantic -std=c++98 as compiler flags. It will keep your code portable and will allow you to create more standarized programs.

Here is a full compiling example of the core ideas in this post:

class A {
public:
	A();
	~A();
};

class B : public A {
public:
	B();
	~B();
};

A::A() {
}

A::~A() {
}

B::B() : A() {
}

B::~B() {
}

int
main(int argc, char **argv)
{

	A *ptr_a = new A();
	B *ptr_b = new B();

	A *a_1 = static_cast<A *>(ptr_b);
	B *b_1 = static_cast<B *>(ptr_a);

	A *a_2 = dynamic_cast<A *>(ptr_b);

	A *a_3 = reinterpret_cast<A *>(ptr_b);
	B *b_3 = reinterpret_cast<B *>(ptr_a);

	const A *a_4 = const_cast<A *>(ptr_a);
	const B *b_4 = const_cast<B *>(ptr_b);

	delete ptr_a;
	delete ptr_b;

	return 0;

}

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

daemon configuration

The daemon is quite easy to configure, you must setup the snmptrapd.conf(5snmp) file. For this configuration, you must read your desired configuration options, such as logging and execution. For example if we have a community called inetsnmp, we can configure the file to allow traps from that community and also configure a trap handler written in perl.

# configure inetsnmp community to allow logging,
# execution of handlers and network traffic.
authCommunity   log,execute,net         inetsnmp

# perl embeded handler.
perl do "/usr/share/snmp/handler/trapdembed.pl"

This configuration is not enough, the snmptrapd(8) daemon uses hosts.allow(5) facility, so we need to add the proper rule in that file:

snmptrapd : 192.168.100.0/255.255.255.0 : allow
snmptrapd : 10.10.10.0/255.255.255.0 : allow

the embeded perl handler

#!/usr/bin/perl -w
#

# strict perl is better
use strict;
use FileHandle;
use Data::Dumper;
use NetSNMP::TrapReceiver;

# we create a sample/demo log file...
my $log = FileHandle->new("/var/log/snmptrapsample.log", "a+") ||
    die "Failed to open log file";

# how we process an SNMP variable
sub process_var {
    my ($var) = @_;
    my %res;
    my $name = "$var->[0]";
    my ($vt, $vv) = split /: /, "$var->[1]";
    $res{'oid'} = $name;
    $res{'type'} = $vt;
    $res{'value'} = $vv;
    return \%res;
}

# our default receiver
sub default_receiver {
    my ($pdu, $ivars) = @_;
    my %vars;
    $log->print(Dumper($pdu));
    foreach my $k (@{$_[1]}) {
        $vars{$k->[0]} = process_var($k);
    }
    $log->print(Dumper(\%vars));
    $log->flush;
}

# every OIDs pass through the default_receiver
NetSNMP::TrapReceiver::register("all", \&default_receiver) ||
    die "Failed to laod Sample Trap Receiver\n";

# status message...
print STDERR "Loaded Sample Trap Receiver\n";

This perl(1) handler will allow you basically to create a handler which is capable to process SNMP notifications creating two main variables on the handler itself $pdu which is the reference to the %pdu hash and %vars hash. Both hashes contains the proper data to process the request as you want:

%pdu = {
    'notificationtype' => 'TRAP',
    'receivedfrom' => 'UDP: [10.10.10.1]:53951->[192.168.100.5]',
    'version' => 1,
    'errorstatus' => 0,
    'messageid' => 0,
    'community' => 'public',
    'transactionid' => 1,
    'errorindex' => 0,
    'requestid' => 1012897136
};

%vars = {
    'IF-MIB::ifDescr' => {
        'value' => 'eth0',
        'type' => 'STRING',
        'oid' => 'IF-MIB::ifDescr'
    },
    'IF-MIB::ifAdminStatus.1' => {
        'value' => '1',
        'type' => 'INTEGER',
        'oid' => 'IF-MIB::ifAdminStatus.1'
    },
    'DISMAN-EVENT-MIB::sysUpTimeInstance' => {
        'value' => '(0) 0:00:00.00',
        'type' => 'Timeticks',
        'oid' => 'DISMAN-EVENT-MIB::sysUpTimeInstance'
    },
    'IF-MIB::ifIndex.1' => {
        'value' => '1',
        'type' => 'INTEGER',
        'oid' => 'IF-MIB::ifIndex.1'
    },
    'SNMPv2-MIB::snmpTrapOID.0' => {
        'value' => 'IF-MIB::linkUp',
        'type' => 'OID',
        'oid' => 'SNMPv2-MIB::snmpTrapOID.0'
    },
    'IF-MIB::ifOperStatus.1' => {
        'value' => '1',
        'type' => 'INTEGER',
        'oid' => 'IF-MIB::ifOperStatus.1'
    }
};

Where each OID or variable, can be treated by using the NetSNMP::OID package. Fora stdin handler, if you don’t know about perl(1), the difference is made on the snmptrapd.conf(5snmp) file, instead of configuring a global perl script which itself registers which OIDs will handle, you need to configure a global trap handler or each handler for each OID that you want to handle:

# configure inetsnmp community to allow logging,
# execution of handlers and network traffic.
authCommunity   log,execute,net         inetsnmp

traphandle     default           /usr/share/snmp/handler/defaultstding.py   default
traphandle     IF-MIB::linkUp    /usr/share/snmp/handler/ifuphandler.py     up

This will make your script or application to receive the OID data from stdin as follows:

router
UDP: [10.10.10.1]:37745->[192.168.100.5]
DISMAN-EVENT-MIB::sysUpTimeInstance 0:0:00:00.00
SNMPv2-MIB::snmpTrapOID.0 IF-MIB::linkUp
IF-MIB::ifIndex.1 1
IF-MIB::ifAdminStatus.1 up
IF-MIB::ifOperStatus.1 up
IF-MIB::ifDescr eth0

And also will require that you will enable in some manner the processing of that data as plain text.

Good luck configuring SNMP traps

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

named columns

Use named columns, instead of using the * wildcard. For example:

select
    t.*
from
    tbl as t
where
    t.tab_date > current_date - interval 1 month
order by
    t.tab_date desc;

Will be more slower than:

select
    t.tab_id,
    t.tab_state,
    t.tab_date,
    t.tab_name
from
    tbl as t
where
    t.tab_date > current_date - interval 1 month
order by
    t.tab_date desc

join filtering

If you filter on join, your query will be faster, for example:

select
    t1.tab_id,
    coalesce(t2.tab_date, current_date) as tab_date,
    t1.tab_name
from
    table1 as t1
        left join table2 as t2 on (t1.tab_id = t2.tab_tab_id)
where
    t2.tab_date IS NULL or t2.tab_date > current_date - interval 1 month;

Will be more slower than

select
    t1.tab_id,
    coalesce(t2.tab_date, current_date) as tab_date,
    t1.tab_name
from
    table1 as t1
        left join table2 as t2 on (t1.tab_id = t2.tab_tab_id
            and t2.tab_date > current_date - interval 1 month);

smaller set first

The smaller set must selected first, for example:

select
    t1.tab_id,
    coalesce(t2.tab_date, current_date) as tab_date,
    t1.tab_name
from
    table1 as t1
        left join table2 as t2 on (t2.tab_tab_id = t1.tab_id
            and t2.tab_date > current_date - interval 1 month);

Will be more slower than:

select
    t1.tab_id,
    coalesce(t2.tab_date, current_date) as tab_date,
    t1.tab_name
from
    table1 as t1
        left join table2 as t2 on (t1.tab_id = t2.tab_tab_id
            and t2.tab_date > current_date - interval 1 month);

Since t1 has less rows than t2, and t2 is referencing t1. Assuming that t1 has a smaller set of rows and is the referenced table. This applies to column selection too and where statements.

notes

You must measure the time of your queries, so you can have a more precise query. Those rules are not absolute.

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

Hello Python Community.

I’m pleased to announce pyxser-1.4.4r, a python extension which contains functions to serialize and deserialize Python Objects into XML. It is a model based serializer. Here is the ChangeLog entry for this release:

1.4.4r (2010.02.10):

        Daniel Molina Wegener 

        * src/include/pyxser_collections.h - added set handling
        function prototypes. Added support for unicode
        key names, which are converted to the user settings
        encoding (ie utf-8) inside the XML output.
        * src/pyxser_serializer.c - removed memory leak. Addded
        support for unicode object names in dictionary/list types.
        * src/pyxser_collections.c - added set handling function
        prototypes. added name property handling algorithm, so
        non string name properties are not serialized. I shall
        extend it to other modules.
        * src/pyxser_tools.c - added set handling prototypes and
        set type checking function.
        * test-utf8-leak.py - added serialization of SQL Alchemy
        objects, so we can test more complex Python objects
        serialization.
        * test-utf8-sqlalchemy.py - added sql alchemy object
        serialization test.
        * src/pyxser_serializer.c - reduced serialization algorithms,
        replacing deep nested if statements by flatten ones.
        * src/pyxser_collections.c - reduced serialization algorithms
        replacing deep nested if statements by flatten ones.
        * src/pyxser_typem.c - reduced serialization algorithms,
        replacing deep nested if statements by flatten ones.

        Thanks to pyxser users for their feedback.

This release contains some bug fixes, mainly related to type checking and type handling. I hope this small extension will help you on your programming tasks.

• The project is hosted at:
  http://sourceforge.net/projects/pyxser/
• The web page for the project is located at:
  http://coder.cl/products/pyxser/
• PyPi entry is:
  http://pypi.python.org/pypi/pyxser/1.4.4r
• For a sample article on how to integrate pyxser with ZSI WebServices:
  http://coder.cl/2009/10/18/pyxser-and-zsi-webservices/

Thanks and best regards…

I hope that this module can help you in your development tasks and thanks for your feedback.

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

table design

You must follow a simple rule, fixed length data types goes first, from the one that fits with CPU register length to those types that have variable length. For example a a simple table design for MySQL could be as follows:

CREATE TABLE customer
(
    customer_id bigint(11) NOT NULL AUTO_INCREMENT,
    cus_priority int NOT NULL,
    cus_state int NOT NULL,
    cus_products int NOT NULL,
    cus_date datetime NOT NULL,
    cus_name varchar(100) NOT NULL,
    cus_email varchar(50) NOT NULL,
    PRIMARY KEY USING BTREE (customer_id)
)
ENGINE= InnoDB DEFAULT CHARSET= utf8

If you take a look on the column order, fixed length table keys have the first priority, fixed length data types have the second priority and the last priority on the table creation script is for those types with variable length. From the perspective of the RDBMS system that we are using, the table structure is read the first time that we query the table, then each fixed length column is read in sequence as the RDBMS systems reads each row from the disk or memory, hence each non-fixed length column is read consequently each time that a row is handled, reading the column length first and then skipping the column offset on the disk or memory to handle the next column. So, reading non-fixed length columns is hard for the RDBMS.

Imagine those tables created with variable length keys!, those tables are creating a heavy overhead on any kind of table created. So, try to use table keys of fixed length, such as int and bigint. Including those tables which have a fixed length made of char(n), are creating a heavy overhead, since those tables are using string comparison algorithms instead of memory block comparison, such as comparing integer types, which is more easy to handle.

Using a naming convention matters too. The table above has a lowercase name, lower case table fields and each field has a prefix related to the table. Why does they have a prefix?, while we are querying a table is more comfortable to identify them by the prefix that they have, specially when we are creating joined queries, allowing unique column identifiers.

query optimisation

Some older RDBMS systems do not support the usage of the join keyword, so we must create joined queries using the where statement. But nowdays in most RDBMS systems supports the join keyword, allowing more faster queries, so there is a technique allowing us to create joins from the older way of using where statements.

select
    pro.product_id,
    pro.pro_name,
    sum(coalesce(pay.pay_price, 0.0)) as payment
from
    product as pro
        left join subscription as sus on (pro.product_id = sus.product_id)
        left join payment as pay on (sus.payment_id = pay.payment_id)
group by
    pro.product_id,
    pro.pro_name
order by
    pro.product_id,
    pro.pro_name

The query above will bring us a report about payments related to each product on the database. If you see there is no where statement. Also, examine the join conditionals, the smallest dataset is filtered at the left side of the conditional. The more we filter on the join conditionals, faster is the query result. That query took just 0.002 seconds. Let’s see what happens with a non-joined query and using the where statement.

select
    pro.product_id,
    pro.pro_name,
    sum(coalesce(pay.pay_price, 0.0)) as payments
from
    product as pro,
    subscription as sus,
    payment as pay
where
    (pro.product_id = sus.product_id and sus.product_id is not null)
    and (pro.product_id = sus.product_id or sus.product_id is null)
    and (sus.payment_id = pay.payment_id or pay.payment_id is null)
group by
    pro.product_id,
    pro.pro_name
order by
    pro.product_id,
    pro.pro_name

Using the where statement, the same query took 0.012 seconds. What happened behind on the RDBMS side? On the first query, row filtering was made while the RDBMS was reading rows from each table, hence on the second query, the selection was made over the complete dataset retrieved from all selection tables. In this case we have an enhancement of 600% on performance, on more complex queries the same happens. Also the having clause is evil too, since it process those rows retrieved after the selection process on those rows retrieved on at last.

select
    pro.product_id,
    pro.pro_name,
    sum(coalesce(pay.pay_price, 0.0)) as payment
from
    product as pro
        left join subscription as sus on (pro.product_id = sus.product_id)
        left join payment as pay on (sus.payment_id = pay.payment_id)
group by
    pro.product_id,
    pro.pro_name
having
    payment > 200000
order by
    pro.product_id,
    pro.pro_name

The having clause can process aggregate columns, but that processing is made at end of the selection process, so you must try to replace that having clause by other join or where statement if you have an option to do that.

rdbms tuning

Each RDBMS has its own parameters. For example, MySQL have some parameters which allow you to have entire tables on memory, so most queries to those tables in memory are faster than reading the hard drive. If you have a system that is querying a database concurrently, you should increase the memory limit, allowing the RDBMS to maintain that table on memory. You must research which options fits for better on the RDBMS that you are using, which kind of keys and table format fits better with your needs. For example on MySQL InnoDB table format is not always the best option, since InnoDB require the highest resource usage, over other kind of tables available on MySQL RDBMS.

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

control classes and interfaces

We can hold our business logic on separate classes. As example we will use a bank loan application, which is supposed to bring us the proper load for certain kind of customers of a bank. So, we need to define an interface pf the loan component.

interface Loan {
    void setUserData(User bankUser);
    void setCustomerData(Customer cus, Account acc);
    LoanResults getLoanResults();
}

This simple interface should be implemented by a variety of Loan types, from consumer ones to mortgage ones, since this variety of loans have different evaluation and estimation logic.

Now we need to define a way to instantiate the proper Loan implementation. The proper Loan implementation request is on the hands of the control layer, since the Loan interface is the abstraction layer itself. So, if we have to need the same methods for every Loan that we request, we just use a Factory Pattern returning the interface Loan, instead of his real implementation.

the abstraction layer

The abstraction layer is implemented on the Loan interface and its returning implementation based on the factory pattern. So we need to implement the factory outside of the package that holds that set of interfaces and implementations. The factory also hold the logic that decides which Loan implementation will be returned, based on the user data, customer data and account data. So we need a call similar to this one:

Loan loanRequest = LoanFactory.getInstance(data);
LoanResults requestResults = loanRequest.getLoanResults();

So, the factory and the loan interface holds the abstraction layer, separating the decoupling the business logic from its real implementation and generating more cohesion. What does the loan request form in the application about those components? The answer is quiet simple: nothing. We will use another pattern to hold input data and pass it through the abstraction layer from the presentation layer. Here is when we are doing dependency injection.

the presentation layer

The presentation layer, which in this case holds a simple LoanRequestForm will never know which concrete class will be used to deliver the LoanResults, so we have to define an instance of another pattern, an Adapter. The adapter should transform the input data from the LoanRequestForm to some kind of Data Transfer Object, to be passed to the factory as CustomerData.

class LoanRequestForm {
    protected Customer cus;
    protected User usr;
    protected Account acc;
    protected LoanRequestFormAdapter adapter = new LoanRequestFormAdapter();
    protected Loan loanRequest;

    LoanResults getLoanResults() {
        try {
            loanRequest = LoanFactory.getInstance(adapter.transform(this));
            LoanResults requestResults = loanRequest.getLoanResults();
            return requestResults;
        } catch (InvalidDataException ex) {
            log.error(ex);
        }
    }
}

Here we are injecting a dependency for the LoanRequestForm and also we acquiring abstraction through the LoanFactory, transforming its input using the LoanRequestFormAdapter to transform the form data into a DTO (Data Transfer Object). The business logic is completely separated from the its User Interface and the abstraction layer. So we are fitting the model with PAC pattern and the IoC DI pattern at once.

The transformation between the form and the factory is a must. The factory can not depend on the form and the form can not depend on the factory. The adapter plays an important role here, since it’s separating layers and transforming the application into an n-tier architected application, so we have more control over changes and possible enhancements on the model. Also it will bring us possible automated processes, since the factory do not needs the form to operate over the loan. So you build another application that just handles the user data and generate loan bids automatically to the customers based on the same logic, then we are reusing the properly the code.

conclusion

We can glue the PAC pattern with IoC DI pattern, so we have more reliable and flexible GUI implementations, then we can work in our platforms without worries about how to generate reusable code if we follow well designed and well applied patterns. Also we can use frameworks, but it depends on the application size and how do need to work on it. For an application with just two active forms, we do not need large scale architectures.

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

• Correctness:

  Software correctness can be established using many techniques and tools, from static analysis, runtime checkers and formal verification. So we have enough tools to determine whether or not the software is correct. Also we can search for the proper algorithm, previously verified and tested to being used in our software.

• Robustness:

  We must try to create small and efficient code, regarding correctness and documenting it, so can create hardened code based on common standards to allow reliable modifications while we are maintaining the code. Jon Postel‘s law says: "Be conservative in what you do; be liberal in what you accept from others". This also reduces the amount of bugs that you can find on your applications.

• Efficiency:

  Efficient code has lower times and reduced cyclomatic complexity. For example we must prefer a construct that is O(1) instead of one that is O(n), if it is available, and we must prefer a construct that has a cyclomatic complexity of 78 rather than other with 129: "simplicity is divine".

• Portability:

  The code must be portable. To create portable code we must simply omit the usage of language/platform specific features. There many standards that we can follow to create portable code and there also are compiler options to help us in that task. For example, GCC supports pedantic compiling flags to regard the strictness of some standards, try compiling your C code with: -Wall -Wextra -Wshadow -pedantic -std=c99, or your C++ code with: -Wall -Wextra -Wshadow -pedantic -std=c++98. Also there is a compiler with the portability issue in mind, the TENDRA compiler, it comes with a static analysis tool too.

• Expressiveness:

  We must create legible code, this principle holds well known coding standards, naming conventions and similar scopes on how do we write the code, to let others read your code and understand it with a faster lookup to the documentation. Also documenting the code is a must. I’m sure that you can follow some standard on coding.

• Flexibility:

  We must try to use abstraction in our code, instead of concrete system calls. For example we have dirent on UNIX and WIN32_FIND_DATA on Windows, both structures are completely different and most Win32 API calls aren’t based on any known standard, so we need to create or use some kind of abstraction to access the system calls, like the Façade design pattern, to allow us to omit direct calls and create more flexible code, and easy to maintain.

• Modularity:

  It’s fully recommended that we must think on terms of OOP. For C programmers the book "Object-oriented programming with ANSI-C" possibly is a must read. Modularity bring us the robustness needed to operate on terms of cohesion, like any desired architecture, we want to implement cohesion instead of attachment, so we can create reusable code and modules.

• Discoverability:

  legible and modular code bring us a good discoverability, so we can establish good basis on well known standard APIs, like POSIX, C++0x and many others. This regards the intuitive approach of building portable code, so we can guess about how is called the function or class that we need to use in our problem.

• Transparency:

  In conjunction with modularity, transparency can bring us the proper cohesion between our software components. The proper abstraction layer between the application tiers allow us to create individual components that work together without attachment and with the proper cohesion. So the maintainability of the application becomes higher and easy.

And here comes some questions: How can we measure all those points?; How can we become more strict and bring more reliable applications?. We must follow some steps to reach optimal software development process. The first one is to define the application architecture, so we can handle common problems with the proper architectural patterns. Then we must fit those architectural patterns with the proper design patterns. One time defined the application architecture we must design our components following that architecture. If we are using Agile Methodologies, we need a well defined architecture too, so we can follow a common paradigm on how to solve the problem that the application is solving.

Using third party frameworks or third party libraries is not a bad practice, but we must be constantly following its roadmap, looking the direction that the library or framework is following, so we can handle properly an incoming and imminent update. How to handle that issue?, using abstractions and modularity, which also reduces the amount of bugs. Here some patterns plays an important role in our quality goals, for example the façade, factory and dependency inyection patterns would help us on that task.

conclusion

The more rigorous we are, we can get more reliable software. But sometimes we don’t have enough time or simply we don’t need to be too rigurous, for example we can not apply formal verification to enterprise applications, because usually those applications have millions of lines of code, instead possibly we can deliver just one module at time that has been verified formally. Instead we can use metrics analyzers, static analyzers and runtime checkers to bring us a better approach on how the code is working. You can learn code hardening techniques and debugging techniques to ensure your code too, which will bring you a better code if you get well taught on those topics.

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

pyxser

pyxser have about one year of development, some months doing research, and other months doing development or coding the Python Module.

And the SVN log show an average hour for commits between 22:00 and 23:00

r125 | damowe | 2010-02-10 16:15:49 -0300 (Wed, 10 Feb 2010) | 2 lines
r124 | damowe | 2010-02-10 15:52:31 -0300 (Wed, 10 Feb 2010) | 2 lines
r123 | damowe | 2010-02-10 13:30:15 -0300 (Wed, 10 Feb 2010) | 10 lines
r122 | damowe | 2010-02-02 08:47:07 -0300 (Tue, 02 Feb 2010) | 3 lines
r121 | damowe | 2009-12-26 21:52:49 -0300 (Sat, 26 Dec 2009) | 2 lines
r118 | damowe | 2009-12-26 21:40:33 -0300 (Sat, 26 Dec 2009) | 2 lines
r117 | damowe | 2009-12-25 15:20:30 -0300 (Fri, 25 Dec 2009) | 4 lines
r116 | damowe | 2009-12-22 20:09:25 -0300 (Tue, 22 Dec 2009) | 5 lines
r115 | damowe | 2009-12-21 19:47:50 -0300 (Mon, 21 Dec 2009) | 2 lines
r114 | damowe | 2009-12-20 01:38:45 -0300 (Sun, 20 Dec 2009) | 7 lines
r112 | damowe | 2009-12-03 09:48:41 -0300 (Thu, 03 Dec 2009) | 6 lines
r110 | damowe | 2009-11-30 14:52:10 -0300 (Mon, 30 Nov 2009) | 2 lines
r109 | damowe | 2009-11-30 14:46:43 -0300 (Mon, 30 Nov 2009) | 9 lines
r107 | damowe | 2009-08-23 11:43:52 -0400 (Sun, 23 Aug 2009) | 2 lines
r102 | damowe | 2009-08-23 11:29:07 -0400 (Sun, 23 Aug 2009) | 2 lines
r99 | damowe | 2009-08-23 11:12:20 -0400 (Sun, 23 Aug 2009) | 6 lines
r98 | damowe | 2009-08-08 15:15:07 -0400 (Sat, 08 Aug 2009) | 3 lines
r93 | damowe | 2009-07-28 21:59:10 -0400 (Tue, 28 Jul 2009) | 2 lines
r90 | damowe | 2009-07-27 22:22:55 -0400 (Mon, 27 Jul 2009) | 2 lines
r89 | damowe | 2009-07-27 22:21:50 -0400 (Mon, 27 Jul 2009) | 5 lines
r88 | damowe | 2009-07-26 22:27:23 -0400 (Sun, 26 Jul 2009) | 4 lines
r87 | damowe | 2009-07-20 16:02:27 -0400 (Mon, 20 Jul 2009) | 5 lines
r86 | damowe | 2009-07-17 22:24:53 -0400 (Fri, 17 Jul 2009) | 4 lines
r84 | damowe | 2009-05-09 23:19:49 -0400 (Sat, 09 May 2009) | 2 lines
r83 | damowe | 2009-05-09 22:31:00 -0400 (Sat, 09 May 2009) | 7 lines
r82 | damowe | 2009-05-09 11:00:44 -0400 (Sat, 09 May 2009) | 3 lines
r81 | damowe | 2009-05-08 21:31:56 -0400 (Fri, 08 May 2009) | 2 lines
r80 | damowe | 2009-04-28 00:32:53 -0400 (Tue, 28 Apr 2009) | 3 lines
r78 | damowe | 2009-04-26 19:21:16 -0400 (Sun, 26 Apr 2009) | 2 lines
r77 | damowe | 2009-04-26 19:13:26 -0400 (Sun, 26 Apr 2009) | 2 lines
r76 | damowe | 2009-04-26 17:34:09 -0400 (Sun, 26 Apr 2009) | 4 lines
r75 | damowe | 2009-04-25 19:31:45 -0400 (Sat, 25 Apr 2009) | 3 lines
r74 | damowe | 2009-04-24 20:49:40 -0400 (Fri, 24 Apr 2009) | 3 lines
r73 | damowe | 2009-04-23 23:06:46 -0400 (Thu, 23 Apr 2009) | 4 lines
r72 | damowe | 2009-04-22 08:28:31 -0400 (Wed, 22 Apr 2009) | 3 lines
r71 | damowe | 2009-04-22 00:52:12 -0400 (Wed, 22 Apr 2009) | 2 lines
r70 | damowe | 2009-04-22 00:28:48 -0400 (Wed, 22 Apr 2009) | 3 lines
r69 | damowe | 2009-04-21 23:09:09 -0400 (Tue, 21 Apr 2009) | 2 lines
r68 | damowe | 2009-04-21 16:41:11 -0400 (Tue, 21 Apr 2009) | 3 lines
r65 | damowe | 2009-04-19 01:24:34 -0400 (Sun, 19 Apr 2009) | 2 lines
r64 | damowe | 2009-04-19 01:22:15 -0400 (Sun, 19 Apr 2009) | 2 lines
r63 | damowe | 2009-04-19 01:17:29 -0400 (Sun, 19 Apr 2009) | 2 lines
r62 | damowe | 2009-04-19 01:10:33 -0400 (Sun, 19 Apr 2009) | 2 lines
r61 | damowe | 2009-04-19 00:01:47 -0400 (Sun, 19 Apr 2009) | 3 lines
r59 | damowe | 2009-04-18 22:57:01 -0400 (Sat, 18 Apr 2009) | 2 lines
r58 | damowe | 2009-04-18 22:30:30 -0400 (Sat, 18 Apr 2009) | 3 lines
r57 | damowe | 2009-04-18 04:26:58 -0400 (Sat, 18 Apr 2009) | 2 lines
r56 | damowe | 2009-04-18 03:28:56 -0400 (Sat, 18 Apr 2009) | 3 lines
r55 | damowe | 2009-04-15 23:38:34 -0400 (Wed, 15 Apr 2009) | 2 lines
r54 | damowe | 2009-04-15 23:10:32 -0400 (Wed, 15 Apr 2009) | 2 lines
r53 | damowe | 2009-04-15 22:46:15 -0400 (Wed, 15 Apr 2009) | 3 lines
r52 | damowe | 2009-04-10 18:30:22 -0400 (Fri, 10 Apr 2009) | 2 lines
r49 | damowe | 2009-04-10 00:17:25 -0400 (Fri, 10 Apr 2009) | 2 lines
r47 | damowe | 2009-04-08 23:43:50 -0400 (Wed, 08 Apr 2009) | 4 lines
r46 | damowe | 2009-04-08 14:29:42 -0400 (Wed, 08 Apr 2009) | 4 lines
r45 | damowe | 2009-04-08 01:31:22 -0400 (Wed, 08 Apr 2009) | 2 lines
r44 | damowe | 2009-04-08 01:30:18 -0400 (Wed, 08 Apr 2009) | 2 lines
r43 | damowe | 2009-04-08 01:28:36 -0400 (Wed, 08 Apr 2009) | 3 lines
r42 | damowe | 2009-04-06 21:58:57 -0400 (Mon, 06 Apr 2009) | 2 lines
r41 | damowe | 2009-04-06 21:46:19 -0400 (Mon, 06 Apr 2009) | 2 lines
r40 | damowe | 2009-04-06 21:36:55 -0400 (Mon, 06 Apr 2009) | 3 lines
r39 | damowe | 2009-04-05 22:25:50 -0400 (Sun, 05 Apr 2009) | 2 lines
r38 | damowe | 2009-04-05 22:19:10 -0400 (Sun, 05 Apr 2009) | 4 lines
r37 | damowe | 2009-04-04 20:18:15 -0400 (Sat, 04 Apr 2009) | 3 lines
r36 | damowe | 2009-03-31 23:49:23 -0400 (Tue, 31 Mar 2009) | 5 lines
r33 | damowe | 2009-03-28 12:13:41 -0400 (Sat, 28 Mar 2009) | 2 lines
r30 | damowe | 2009-03-26 22:17:10 -0400 (Thu, 26 Mar 2009) | 3 lines
r29 | damowe | 2009-03-26 21:59:57 -0400 (Thu, 26 Mar 2009) | 5 lines
r28 | damowe | 2009-03-26 21:17:10 -0400 (Thu, 26 Mar 2009) | 2 lines
r27 | damowe | 2009-03-25 23:26:30 -0400 (Wed, 25 Mar 2009) | 3 lines
r26 | damowe | 2009-03-25 22:58:16 -0400 (Wed, 25 Mar 2009) | 5 lines
r25 | damowe | 2009-03-25 22:03:16 -0400 (Wed, 25 Mar 2009) | 2 lines
r24 | damowe | 2009-03-25 21:00:44 -0400 (Wed, 25 Mar 2009) | 4 lines
r23 | damowe | 2009-03-25 20:48:26 -0400 (Wed, 25 Mar 2009) | 3 lines
r22 | damowe | 2009-03-25 20:34:30 -0400 (Wed, 25 Mar 2009) | 2 lines
r21 | damowe | 2009-03-25 20:15:58 -0400 (Wed, 25 Mar 2009) | 2 lines
r20 | damowe | 2009-03-24 20:47:42 -0400 (Tue, 24 Mar 2009) | 2 lines
r19 | damowe | 2009-03-23 23:41:47 -0400 (Mon, 23 Mar 2009) | 5 lines
r18 | damowe | 2009-03-23 21:03:13 -0400 (Mon, 23 Mar 2009) | 3 lines
r17 | damowe | 2009-03-23 20:16:58 -0400 (Mon, 23 Mar 2009) | 2 lines
r16 | damowe | 2009-03-19 22:57:46 -0400 (Thu, 19 Mar 2009) | 2 lines
r15 | damowe | 2009-03-19 22:30:56 -0400 (Thu, 19 Mar 2009) | 5 lines
r14 | damowe | 2009-03-19 20:37:13 -0400 (Thu, 19 Mar 2009) | 2 lines
r13 | damowe | 2009-03-19 00:37:39 -0400 (Thu, 19 Mar 2009) | 3 lines
r12 | damowe | 2009-03-19 00:11:23 -0400 (Thu, 19 Mar 2009) | 3 lines
r11 | damowe | 2009-03-18 23:47:08 -0400 (Wed, 18 Mar 2009) | 3 lines
r10 | damowe | 2009-03-17 22:25:47 -0400 (Tue, 17 Mar 2009) | 2 lines
r9 | damowe | 2009-03-17 22:23:21 -0400 (Tue, 17 Mar 2009) | 2 lines
r8 | damowe | 2009-03-17 22:16:37 -0400 (Tue, 17 Mar 2009) | 2 lines
r7 | damowe | 2009-03-17 00:55:43 -0400 (Tue, 17 Mar 2009) | 2 lines
r6 | damowe | 2009-03-16 23:33:31 -0400 (Mon, 16 Mar 2009) | 2 lines
r5 | damowe | 2009-03-15 17:21:57 -0400 (Sun, 15 Mar 2009) | 2 lines
r4 | damowe | 2009-03-15 17:07:39 -0400 (Sun, 15 Mar 2009) | 2 lines
r1 | damowe | 2009-03-15 15:35:31 -0400 (Sun, 15 Mar 2009) | 2 lines

The project has 6,198 lines of code… a good effort and a good product. During the day I must work on those projects which bring me money, at night and as hobbits I work on my FOSS projects. I have a little time to work on them.

caffeine

caffeine or C Application Framework has 14,177 lines of code, and it is evaluated as one project with three humans working on it, but it is really one, me.

And the SVN log show an average hour for commits between 22:00 and 23:00

r125 | damowe | 2009-09-30 14:45:06 -0400 (Wed, 30 Sep 2009) | 6 lines
r124 | damowe | 2009-09-26 18:49:31 -0400 (Sat, 26 Sep 2009) | 2 lines
r123 | damowe | 2009-09-26 17:46:26 -0400 (Sat, 26 Sep 2009) | 5 lines
r122 | damowe | 2009-09-26 13:14:50 -0400 (Sat, 26 Sep 2009) | 2 lines
r121 | damowe | 2009-09-26 12:25:19 -0400 (Sat, 26 Sep 2009) | 4 lines
r120 | damowe | 2009-09-22 05:18:11 -0400 (Tue, 22 Sep 2009) | 8 lines
r119 | damowe | 2009-09-19 23:27:06 -0400 (Sat, 19 Sep 2009) | 5 lines
r118 | damowe | 2009-09-19 19:06:50 -0400 (Sat, 19 Sep 2009) | 8 lines
r117 | damowe | 2009-09-01 22:18:54 -0400 (Tue, 01 Sep 2009) | 5 lines
r116 | damowe | 2008-10-27 07:40:14 -0300 (Mon, 27 Oct 2008) | 2 lines
r115 | damowe | 2008-10-27 07:38:30 -0300 (Mon, 27 Oct 2008) | 2 lines
r114 | damowe | 2008-10-27 07:35:09 -0300 (Mon, 27 Oct 2008) | 3 lines
r113 | damowe | 2008-10-25 13:01:20 -0300 (Sat, 25 Oct 2008) | 2 lines
r112 | damowe | 2008-06-10 21:10:30 -0400 (Tue, 10 Jun 2008) | 3 lines
r111 | damowe | 2008-06-06 20:05:39 -0400 (Fri, 06 Jun 2008) | 5 lines
r110 | damowe | 2008-05-08 21:12:50 -0400 (Thu, 08 May 2008) | 2 lines
r109 | damowe | 2008-05-06 23:53:10 -0400 (Tue, 06 May 2008) | 2 lines
r108 | damowe | 2008-05-05 23:37:42 -0400 (Mon, 05 May 2008) | 2 lines
r107 | damowe | 2008-04-27 02:08:49 -0400 (Sun, 27 Apr 2008) | 2 lines
r106 | damowe | 2008-04-26 11:59:49 -0400 (Sat, 26 Apr 2008) | 4 lines
r105 | damowe | 2008-04-22 23:06:33 -0400 (Tue, 22 Apr 2008) | 3 lines
r104 | damowe | 2008-04-21 21:13:06 -0400 (Mon, 21 Apr 2008) | 4 lines
r103 | damowe | 2008-02-10 13:16:32 -0300 (Sun, 10 Feb 2008) | 3 lines
r102 | damowe | 2008-02-10 10:22:34 -0300 (Sun, 10 Feb 2008) | 2 lines
r101 | damowe | 2008-02-10 10:08:35 -0300 (Sun, 10 Feb 2008) | 2 lines
r100 | damowe | 2008-01-06 12:07:57 -0300 (Sun, 06 Jan 2008) | 4 lines
r99 | damowe | 2008-01-05 20:03:27 -0300 (Sat, 05 Jan 2008) | 4 lines
r98 | damowe | 2008-01-01 17:29:14 -0300 (Tue, 01 Jan 2008) | 3 lines
r97 | damowe | 2007-12-31 15:47:20 -0300 (Mon, 31 Dec 2007) | 2 lines
r96 | damowe | 2007-12-30 12:15:46 -0300 (Sun, 30 Dec 2007) | 2 lines
r95 | damowe | 2007-12-30 12:06:41 -0300 (Sun, 30 Dec 2007) | 3 lines
r94 | damowe | 2007-12-30 07:59:58 -0300 (Sun, 30 Dec 2007) | 2 lines
r93 | damowe | 2007-12-25 10:37:15 -0300 (Tue, 25 Dec 2007) | 3 lines
r92 | damowe | 2007-12-22 09:57:27 -0300 (Sat, 22 Dec 2007) | 2 lines
r91 | damowe | 2007-12-22 09:56:15 -0300 (Sat, 22 Dec 2007) | 4 lines
r90 | damowe | 2007-12-22 07:26:39 -0300 (Sat, 22 Dec 2007) | 3 lines
r89 | damowe | 2007-12-16 22:21:51 -0300 (Sun, 16 Dec 2007) | 4 lines
r88 | damowe | 2007-12-03 21:35:27 -0300 (Mon, 03 Dec 2007) | 2 lines
r87 | damowe | 2007-12-01 23:56:53 -0300 (Sat, 01 Dec 2007) | 3 lines
r86 | damowe | 2007-12-01 23:44:02 -0300 (Sat, 01 Dec 2007) | 2 lines
r85 | damowe | 2007-11-11 09:06:24 -0300 (Sun, 11 Nov 2007) | 4 lines
r84 | damowe | 2007-11-10 21:43:36 -0300 (Sat, 10 Nov 2007) | 2 lines
r83 | damowe | 2007-11-10 21:25:58 -0300 (Sat, 10 Nov 2007) | 2 lines
r82 | damowe | 2007-10-07 11:39:55 -0400 (Sun, 07 Oct 2007) | 3 lines
r81 | damowe | 2007-10-07 08:32:09 -0400 (Sun, 07 Oct 2007) | 3 lines
r80 | damowe | 2007-09-30 21:53:52 -0400 (Sun, 30 Sep 2007) | 3 lines
r79 | damowe | 2007-09-19 18:27:20 -0400 (Wed, 19 Sep 2007) | 2 lines
r78 | damowe | 2007-09-18 00:34:21 -0400 (Tue, 18 Sep 2007) | 2 lines
r77 | damowe | 2007-09-17 17:10:57 -0400 (Mon, 17 Sep 2007) | 3 lines
r76 | damowe | 2007-09-15 17:27:45 -0400 (Sat, 15 Sep 2007) | 2 lines
r75 | damowe | 2007-09-08 11:19:19 -0400 (Sat, 08 Sep 2007) | 2 lines
r74 | damowe | 2007-09-02 12:11:38 -0400 (Sun, 02 Sep 2007) | 2 lines
r73 | damowe | 2007-09-02 10:57:54 -0400 (Sun, 02 Sep 2007) | 2 lines
r72 | damowe | 2007-09-02 10:55:09 -0400 (Sun, 02 Sep 2007) | 2 lines
r71 | damowe | 2007-09-02 09:38:43 -0400 (Sun, 02 Sep 2007) | 5 lines
r70 | damowe | 2007-09-02 02:13:20 -0400 (Sun, 02 Sep 2007) | 4 lines
r69 | damowe | 2007-08-31 20:05:06 -0400 (Fri, 31 Aug 2007) | 3 lines
r68 | damowe | 2007-08-26 13:34:53 -0400 (Sun, 26 Aug 2007) | 2 lines
r67 | damowe | 2007-08-26 13:15:04 -0400 (Sun, 26 Aug 2007) | 3 lines
r66 | damowe | 2007-08-26 10:10:19 -0400 (Sun, 26 Aug 2007) | 3 lines
r65 | damowe | 2007-08-25 19:00:10 -0400 (Sat, 25 Aug 2007) | 3 lines
r64 | damowe | 2007-08-19 00:26:00 -0400 (Sun, 19 Aug 2007) | 3 lines
r63 | damowe | 2007-08-18 10:36:16 -0400 (Sat, 18 Aug 2007) | 3 lines
r62 | damowe | 2007-08-15 17:23:28 -0400 (Wed, 15 Aug 2007) | 2 lines
r61 | damowe | 2007-08-13 07:48:31 -0400 (Mon, 13 Aug 2007) | 3 lines
r60 | damowe | 2007-08-12 17:06:08 -0400 (Sun, 12 Aug 2007) | 2 lines
r59 | damowe | 2007-08-12 16:33:09 -0400 (Sun, 12 Aug 2007) | 3 lines
r58 | damowe | 2007-08-12 13:39:59 -0400 (Sun, 12 Aug 2007) | 2 lines
r57 | damowe | 2007-08-12 01:26:32 -0400 (Sun, 12 Aug 2007) | 2 lines
r56 | damowe | 2007-08-11 13:26:10 -0400 (Sat, 11 Aug 2007) | 2 lines
r55 | damowe | 2007-08-11 13:21:17 -0400 (Sat, 11 Aug 2007) | 3 lines
r54 | damowe | 2007-08-06 21:58:22 -0400 (Mon, 06 Aug 2007) | 2 lines
r53 | damowe | 2007-08-04 23:03:06 -0400 (Sat, 04 Aug 2007) | 3 lines
r52 | damowe | 2007-08-04 22:39:10 -0400 (Sat, 04 Aug 2007) | 3 lines
r51 | damowe | 2007-08-04 17:28:45 -0400 (Sat, 04 Aug 2007) | 2 lines
r50 | damowe | 2007-08-04 16:54:48 -0400 (Sat, 04 Aug 2007) | 2 lines
r49 | damowe | 2007-07-29 09:15:12 -0400 (Sun, 29 Jul 2007) | 2 lines
r48 | damowe | 2007-07-28 17:38:23 -0400 (Sat, 28 Jul 2007) | 2 lines
r47 | damowe | 2007-07-16 23:45:16 -0400 (Mon, 16 Jul 2007) | 3 lines
r46 | damowe | 2007-07-16 16:47:06 -0400 (Mon, 16 Jul 2007) | 3 lines
r45 | damowe | 2007-07-15 20:03:51 -0400 (Sun, 15 Jul 2007) | 3 lines
r44 | damowe | 2007-07-15 12:10:35 -0400 (Sun, 15 Jul 2007) | 3 lines
r43 | damowe | 2007-07-02 17:30:56 -0400 (Mon, 02 Jul 2007) | 2 lines
r42 | damowe | 2007-07-02 10:46:27 -0400 (Mon, 02 Jul 2007) | 3 lines
r41 | damowe | 2007-06-30 16:23:19 -0400 (Sat, 30 Jun 2007) | 2 lines
r40 | damowe | 2007-06-23 21:08:20 -0400 (Sat, 23 Jun 2007) | 3 lines
r39 | damowe | 2007-06-23 10:37:22 -0400 (Sat, 23 Jun 2007) | 2 lines
r38 | damowe | 2007-06-23 10:33:24 -0400 (Sat, 23 Jun 2007) | 2 lines
r37 | damowe | 2007-06-22 23:10:58 -0400 (Fri, 22 Jun 2007) | 3 lines
r36 | damowe | 2007-06-20 21:57:34 -0400 (Wed, 20 Jun 2007) | 3 lines
r35 | damowe | 2007-06-18 21:22:26 -0400 (Mon, 18 Jun 2007) | 3 lines
r34 | damowe | 2007-06-17 21:33:13 -0400 (Sun, 17 Jun 2007) | 2 lines
r33 | damowe | 2007-06-17 21:31:58 -0400 (Sun, 17 Jun 2007) | 2 lines
r32 | damowe | 2007-06-17 18:48:40 -0400 (Sun, 17 Jun 2007) | 3 lines
r31 | damowe | 2007-06-17 12:03:32 -0400 (Sun, 17 Jun 2007) | 3 lines
r30 | damowe | 2007-06-17 11:50:15 -0400 (Sun, 17 Jun 2007) | 2 lines
r29 | damowe | 2007-06-16 21:48:05 -0400 (Sat, 16 Jun 2007) | 2 lines
r28 | damowe | 2007-06-16 21:43:38 -0400 (Sat, 16 Jun 2007) | 3 lines
r27 | damowe | 2007-06-09 18:25:07 -0400 (Sat, 09 Jun 2007) | 2 lines
r26 | damowe | 2007-06-09 18:05:07 -0400 (Sat, 09 Jun 2007) | 2 lines
r25 | damowe | 2007-06-09 18:03:56 -0400 (Sat, 09 Jun 2007) | 3 lines
r24 | damowe | 2007-06-03 20:45:25 -0400 (Sun, 03 Jun 2007) | 3 lines
r23 | damowe | 2007-06-03 19:08:34 -0400 (Sun, 03 Jun 2007) | 2 lines
r22 | damowe | 2007-06-03 19:07:35 -0400 (Sun, 03 Jun 2007) | 2 lines
r21 | damowe | 2007-05-21 10:48:01 -0400 (Mon, 21 May 2007) | 2 lines
r20 | damowe | 2007-05-20 22:00:12 -0400 (Sun, 20 May 2007) | 2 lines
r19 | damowe | 2007-05-20 21:45:38 -0400 (Sun, 20 May 2007) | 6 lines
r18 | damowe | 2007-05-20 10:57:12 -0400 (Sun, 20 May 2007) | 2 lines
r17 | damowe | 2007-05-19 22:22:24 -0400 (Sat, 19 May 2007) | 5 lines
r16 | damowe | 2007-05-18 21:41:36 -0400 (Fri, 18 May 2007) | 2 lines
r15 | damowe | 2007-05-14 23:02:09 -0400 (Mon, 14 May 2007) | 3 lines
r14 | damowe | 2007-05-13 12:03:47 -0400 (Sun, 13 May 2007) | 2 lines
r13 | damowe | 2007-05-13 01:01:13 -0400 (Sun, 13 May 2007) | 2 lines
r12 | damowe | 2007-05-12 22:48:18 -0400 (Sat, 12 May 2007) | 2 lines
r11 | damowe | 2007-05-12 22:41:14 -0400 (Sat, 12 May 2007) | 3 lines
r10 | damowe | 2007-05-07 08:57:33 -0400 (Mon, 07 May 2007) | 2 lines
r9 | damowe | 2007-05-03 08:37:04 -0400 (Thu, 03 May 2007) | 3 lines
r8 | damowe | 2007-05-02 20:50:25 -0400 (Wed, 02 May 2007) | 3 lines
r7 | damowe | 2007-05-01 17:43:00 -0400 (Tue, 01 May 2007) | 2 lines
r6 | damowe | 2007-05-01 09:31:08 -0400 (Tue, 01 May 2007) | 2 lines
r5 | damowe | 2007-05-01 09:24:07 -0400 (Tue, 01 May 2007) | 1 line
r4 | damowe | 2007-05-01 09:08:02 -0400 (Tue, 01 May 2007) | 2 lines
r3 | damowe | 2007-05-01 09:05:41 -0400 (Tue, 01 May 2007) | 2 lines
r2 | damowe | 2007-05-01 09:04:51 -0400 (Tue, 01 May 2007) | 2 lines
r1 | damowe | 2007-05-01 09:04:22 -0400 (Tue, 01 May 2007) | 2 lines

Both projects requires effort and research, and both project are not simple ones to handle, since they are written in C, a language difficult to learn and handle… I hope that I can continue the foss development that I’ve started, but seems that I have some health problems now

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

1.4.2r (2010.02.10):

        Daniel Molina Wegener <dmw at coder dot cl>
        * pyxser_collections.c: Added constraint checks for NULL
        pointers removing nested statements.
        * pyxser.c: Removed nested statements.
        * pyxser_tools.c: Added constratints checks for NULL pointers,
        removed nested statements and added strict checking for lists
        since it was crashing with an ambigous list definition that
        can not be handled by PyList_Check().
        * test-utf8.py: Added tests to determine if it continue
        crashing with module serialization.

        Thanks to pyxser users for their feedback.

I want to bring special thanks to Dariusz Suchojad for his feedback. I’ve fixed some type checking bugs and minor ones. Now pyxser is capable to do module serialization, but not in concrete one, still is not capable to distribute modules, so it is capable to create a simple module representation as XML, under the pyxser serialization model.

I hope that it will help you on your programming tasks.

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

overview

First we need a concrete class implementing the parser, but it needs an abstraction layer and also something which provides the proper parsing states to its internals. Finally we need to expose those extracted tokens outside of this component — the meta-parser.

Clearly the abstraction is made in top of a single template, the control is given from the ParserService class and the presentation is provided through the Token interface with the proper implementations.

substring automaton

Another interesting point is how specific string parsing is implemented. The system uses an FSM, which implements a simple automaton:

So, parsing the left hand token implies parsing the value token and then it states the right hand token, to complete the cycle reaching again the stored value token . This is used to extract substrings. Where every token is configurable with a proprietary language. Finally, the full parser specific implementation is made on top of state machines which are used according the proper configuration representation using thitd party classes and structures, so is possible to extract the required tokens from the input source.

Also, each configuration and parser instances are designed for concurrency. The project will be running on with parallel tasks inside a mutithreaded — and possibly multiprocess — service daemon. Driven by my client schedule, I can not implement wait free algorithms, so I will be using standard operating system provided locks — and more easy to handle algorithms.

in deep with abstractions

Although the PAC pattern is designed for user interfaces, the usage of this pattern to communicate components and generate strong abstraction layers helps a lot on design and maintainability issues. Indeed, this patterns guarantee a reward while we are coding some design patterns. In this case, for example the MetaParser and the ParserService are both an instance of Adapters, where a transformation is made from one layer to other. While MetaParser is a strong abstraction layer for the given implementations.

Finally ParserService provide us the proper way to handle different parsing tasks, so we can determine inside it which abstraction to use though the proper MetaParser instance.

conclusion

The PAC pattern can be used to implement component communications and proper abstraction between application layers, among the usage on user interfaces. Does it falls in other architectural pattern? Anyone knows?.

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags: