![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
I have been using AppConfig, but it’s goal seems to be something a bit different from what I want.
I have a deep data structure and I just want to be able to deserialize this from a file. Some of the attributes needs to be converted into references to arrays etc.
So I made a swift search on http://search.cpan.org/ located Config::General.
I am skimming through the code and I fall over a section with a complex example:
user = hans
server = mc200
db = maxis
passwd = D3rf$
<jonas>
user = tom
db = unknown
host = mila
<tablestructure>
index int(100000)
name char(100)
prename char(100)
city char(100)
status int(10)
allowed moses
allowed ingram
allowed joice
</tablestructure>
</jonas>
If you look at the example, it contains the string jonas. This word can be uttered in a large group of people with additional background noise, it can be written in a huge text document - and my senses will always pick it up easily - for the hearing part this is referred to as the cocktail party effect. I have no knowledge of an equivalent for reading, but to get back to the example and Config::General.
The match between my name and the example string, is of course purely coincidental, but how can I NOT try out this module now? - better give it a shot.
obra Today's events: I quote Master & Margarita in a release notice; I put Sympathy for the Devil on the stereo; A black cat jumps on my desk.
11:50 PM Oct 2nd from web
jzdziarski Hey 50 midgets just ran in and kicked me in the shins.
11:07 PM Oct 2nd from web
Version2:
http://www.version2.dk/grupper/Perl/kale
Linkedin:
http://events.linkedin.com/Copenhagen-pm-O
Facebook:
http://www.facebook.com/event.php?eid=12
i am currently going over my plugins so find out what I would like to present.
- System Proxy, a plugin to let Firefox use the System Proxy under OSX, too Mac specific, eventhough it has saved me a lot of time
- Live HTTP Headers, viewing headers as request are made, very useful when debugging requests, content-types etc. - it was however recommended to me by a fellow Perl-monger, so it might be taken
- DisableBackspaceNavigation, very simple very nice
- Firebug, I expect this to be picked by somebody else who is more well versed in Javascript debugging
- It’s all text, I used this a lot when blogging on http://use.perl.org/ but since I am now using MacJournal, I do not use it as often anymore
- NoScript, well what more can I say - it is sometimes incredibly annoying, but at the same time it is nice to control your browsing in unknown unchartered waters
- WebDeveloper, nice, I used it a lot when working for a particular client, but currently I am not doing a lot of layout - but I am sure it will come in handy again sometime in the future, again a widely used plugin, so it might be picked up by somebody else
- Speed Dial, Opera had it - nice feature, nice plugin
- Keyconfig, I installed this due to issues with Firefox and editing stuff, since the <command>-<arrow> is used to move the cursor in many editors, it teased me in Firefox (see: http://www.macosxhints.com/article.php?s
Plugins I have for long wanted to get started with:
- YSlow, grading your website and helping address performance issues
- Selenium, automated testing of web pages
The meeting is not until late October, so I have some time to figure out what I want to contribute with
The developer releases on CPAN, releases using the following format:
<major>.<minor>_<developer release>
These release are preliminary releases before a stable release. Lots of CPAN authors/contributors use this scheme and it is supported by CPAN. Many developer releases are however quite useful, at least this is my experience as a CPAN user. Workflows developer releases are however more like a snapshot, reflecting concluded work on a specific branch. They are therefor not recommended for use, unless they address a specific bug you have reported or patch you have sent.
To demonstrate. The last stable release was 1.32. Meaning that the next planned release is 1.33.
Since the release of 1.32, the following releases has been made:
- 1.33_1, patch from Andrew O'Brien, dynamic loading of config files
- 1.33_2, new tests forgotten in distribution, my bad
- 1.33_3, bug fix based on report from Sergei Vyshenski
- 1.33_4, patch from Danny Sadinoff finer grained control of initialization
- 1.33_5, patch from Thomas Erskine, new accessors and a bug fix
All are based on branches and the releases are made from the relevant branch before merging into trunk. The actual merge will not be made until the preparation of the 1.33 release begins.
All branches are based on release 1.32 so the different releases do not contain each other. The reason for this is:
- The releases are made to indicate concluded work on a branch and evaluation can begin by patchers/reporters and other interested parties, as I mentioned earlier
- A release made to CPAN gets thrown at the CPAN-testers, so the release can be smoked
- A branch might be discarded if agreed upon by involved parties
I am not sure what strategy is made by other CPAN authors/contributors, so feedback is very much welcome, since I am not aware of what the best practice is or the de facto use of the developer release scheme.
I have done a lot of work on their admin tool exports, changing format of these, applying business rules and so on. So I thought I might as well release the core component as Open Source.
The module lets you sub-class it and implement a processor taking the downloaded content and manipulate it easily. It is currently not much, but it is a start, more features will follow.
It is also my first Open Source project to be hosted on my Jira Studio. This currently offers:
- Subversion readonly access
- Documentation Wiki (confluence)
I am working on getting issue reporting opened and getting the subversion repository mirrored to Github. I could of course have put it on Github straight away, but currently I am using Subversion and I like using Jira Studio and Greenhopper for work related projects.
I will blog some more on my Open Source efforts in relation to Jira Studio as I get things working.
The sort of issues are as such fixable and often very easy fixes. We have both the knowledge and we have the tools to do so. As I have lined out on that earlier occasion, our organizations sometimes lack the process and QA it takes to make sure that we do not leave our sites vulnerable.
Anyway - working on the issue did however demonstrate some other problems, I had not anticipated.
Picking some modules from CPAN to help me out seemed like a good idea and the component in question was already relying heavily on CPAN modules.
When I first started out, I had separated out the component in question from our core software, the actual portal software. Since the component was actually just a plugin (we call these services), so this was quite easy. This would mean that I could work on it and deploy it without having to deploy a whole lot of unrelated software, which current state I was not totally updated on. Personally I would prefer to isolate and focus on the security issue at hand.
So I cooked up a new distribution, copied the stuff I needed (not much history lost there since we only had the initial revision), deleted it from the core trunk, no dual life for me no sir, and moved on...
I then started building a proper distribution. I threw in my scripted installation process based on a subclass of Module::Build, updated this to reflect that the service was a core server not living on the ordinary application hosts, but on the core hosts, this seemed like an easy fix, documenting it was the hardest part, but I was to become wiser.
I am of that opinion that we should not have first and second rate citizens in our system, a service is a service and should be agnostic to where it is invocated. There is however a big difference between the installations. Where our application servers have a designated special directory outside the control of the local Perl configuration, the core hosts install much of their stuff under the control of the local Perl configuration, this was a bit annoying, but certainly fixable, but it does mean that the two rates of services cannot rely on the same build tool as is. Even though they are both just services.
Another problem with the build tool was that it utilized newer features so I was not compatible with the installed Perl and I was unable to install a newer one, note on revisiting this was made.
Not having a proper build tool to assert my configuration and the sanity of what I was trying to do. I simply had to install the module, by overriding the existing one and trying it out.
First shot (my release 0.02) failed utterly. My use of XML::Simple was simply too fancy, so I had the same problem as I had experienced for Module::Build.
I rewrote the fix using a simpler strategy. This time with the 0.03 release candidate, it at least compiled.
So after a lot of hoop jumping it worked out after some more testing together with a colleague, we nailed the actual security problem.
So to get back to the intro in this blog entry.
We have the tools and we have the knowledge, but as this demonstrates I ended up implementing a less generic solution using a regular expression. Just running the data through some encoding schemes would keep me happier, since regular expressions are often culprits of bugs and the first solution was much more generic and would handle changes better.
So the hindrance for doing the right thing, was actually the platform. Time is slowly catching up with us and the technical debt put upon by using a platform, which has not been kept up to date is starting to interfere with our work and solutions. The platform primary goal is to bring leverage, but now it is putting constraints on us and the work we do.
It would be easy to update the Perl interpreter, but working under time constraints to get a security issue fixes is not the time and place. Updating the Perl interpreter would require extensive regression test, something I am not sure our platform is ready for.
The lesson learned must be that a platform should be maintained using baby-steps, this strategy has proven useful in other situations. This mean that you update in small gradual steps so you do not have to take huge giant leaps, when you finally get to a point where updating is unavoidable.
In the example above I simply added more to the technical debt than was necessary, but I was forced to. I did not make the giant leap, which would probably be a good idea, so the next issue would be easier to address using contemporary versions of the tools at hand.
Do not get me wrong I really like old platforms and in particular this platform, but things should be maintained, because if not they become a nuisance and get exchanged for something new and fancy, which might introduce new bugs, which had been addressed over time on the old platform.
The scanning tool was able to post URI encoded strings, which could be evaluated as working Javascript. This would enable a malicious user to manipulate with the functionality on the page. The functionality in question has nothing to do with the PCI related parts directly, but if your site has a vulnerability, you can loose your PCI certification all together and the people receiving the scans are not so interested in the technical details, they just react to a red flag.
The fix seemed quite obvious after having understood the problem. I would decode all URI encoding to UTF-8 and then I could encode everything as HTML entities prior to propagating it.
The actual implementation did however give me some headaches. To begin with the data was XML. The data was passed untouched through and processed using XSL to render the HTML result for the client.
So in order to perform the decoding and encodings I had planned, I started by transforming the original XML to a native Perl data structure using XML::Simple for easier access.
I implemented the operations and started working on the translation of my cleaned data structure to XML again.
This was not quite as easy as expected and it took several attempts to get the XML in a condition where it resembled the original, this was a goal in itself, since I wanted to avoid making changes to the XSL. The XML did not completely resemble the original, but it was close enough for the XSL to work.
I then set out to test the complete setup on one of the designated hosts, then things really started to go the wrong way. The build tool I am using is based on Module::Build. The Module::Build version required was not compatible with the perl interpreter installed. After a brief moment of disappointment, I just decided to work around the scripted installation process and target the task at hand.
Next disappointment came swiftly, the new version of the software simply did not work. My use of XML::Simple was based on newer features, not supported by the currently installed version. So I attempted an upgrade. The same problem, the contemporary version of XML::Simple was not compatible with the installed perl version.
After some cursing (which I will leave out here), I discussed the problem with the colleague sitting opposite me. Explaining him the problem gave the solution. I would create a simpler fix, avoiding all the data structure transformations and simply using a regular expression.
I revisited my test suite and mocked important components and finally I was able to see the fix working.
This is the second time I experience and XSS vulnerability. The first time, it was introduced by a freelancer I employed and we got a lot of heat from the developer receiving the PCI scan.
As things often go, nemesis sets in and the new vulnerability I am describing here was actually introduced by the same developer who complained over our previous guest appearance in the security scan report.
The most important lessons learned, must be that we will keep introducing new holes. Things that can help us too keep this to a bare minimum must be a combination of the following:
- Peer review of the source code
- Education in understanding holes
- Security Testing
- Introduction of general components to close holes and education in their use
I will get back to knowledge in organizations in a later blog entry.
Suggestions for additional practices are more than welcome, since this is just one war story and not a particularly interesting one, but I am sure I am not the only one who has a story or two on XSS vulnerabilities or similar and the following reflections we make as developers dealing with these.
I also expect to write up a blog entry more on the actual functionality in use, to share my experiences.
I started receiving phone calls with no significant information. I took it quite easy, having worked for this client for a long time, my experience has taught me not to get dragged into the well of mass panic.
The problem was simply described as: “Customers can see each others confidential data”.
So without any major overview of what the problem was, what the impact was, I followed orders and disabled the authentication on the platform, not allowing customers access to confidential data.
The rest of the Thursday afternoon and evening was a combination of phone calls, RT commenting, log examination and source code skimming, with absolutely no idea of what to look for. Attempts to recreate the problem were without success.
A very positive thing was that one of the other developers had taken lead on the assignment, so when people called me I could simply just refer to him, so all information would be going through a single point.
Without being anywhere closer to a solution I went to bed, I did not sleep particularly well, my brain working overtime on the problem.
Friday morning I got in early, we started brainstorming and attempting to gather as many facts as possible. We were unable to get a complete overview of the customer impact. A lot of misunderstandings on the nature of the problem where flourishing in the organization, since everybody wanted to participate and the information we had was scarce and showed no useful patterns.
We tried to gather as much information and started laying out scenarios, investigating dark corners of the systems. The online platform is some 7-8 years having run since 2001 and we had never had any serious issues particularly not of this kind, much of this due my very competent colleagues, no longer employed with the client.
I called the most knowledgeable of my former colleagues and we discussed the problem, he informed me that it would be possible to create the incident we had seen if the customer’s network administrator was either evil or stupid.
Everything pointed to some sort of proxy/caching mechanism.
We got clearance to call the customer from the security people and we interviewed one of the involved customers. The information we got here was again misleading and leading to a dead end.
Saturday we took the day off, even though orders from the corporate powers that be, meant that we should be working our asses off 24/7, we where nothing closer to a resolution.
Maybe I was not at the keyboard Saturday, but my brain was pretty preoccupied with the incident.
Sunday morning we met at the office, we started brainstorming again. The customer we had talked to previously had called our manager with more information. And had stated that he was unable to replicate the problem from home, only when using the work VPN. He had first seen the problem at work. Also the name of the other customer rang a bell since he had seen her name on the work intranet.
During our first interview, I had specifically inquired about possible relations, work/family wise. And whether they were on the same network.
So now things were finally coming together. We had a cache or proxy fooling with our data on a corporate LAN.
I laid out a plan to enable SSL/HTTPS for our authentication, since the session would then be between the client and us. So SSL would act as ice breaker for this piece of equipment on the LAN of the customer’s place of work, doing something we did not anticipate.
After a few changes and some testing on our test environment, I created a list of changes to make and applied them in production. We called up the customer, asked him to test and he was unable to recreate the problem, success.
I still have no idea what exactly was causing the problem, whether it was a badly configured cache or proxy, some security auditing tool or whatever and we simply left it there, after having reestablished the system for all customers.
I was then asked to write a report for the client on what the problem was and what we did to make it go away. At the same time we had identified several places, where improvements could be made to make auditing and logging easier on our side.
So now we have a bunch of stuff to do, including a report for the security department.
I learned a lot from this, like what questions to ask a customer, that it was a good thing to have a single lead on the group of people pursuing the issue and finally, take time and think hard, do not be stressed out by panic struck people. Be hard on the information you get, get at much as you can but be critical, people start to see ghosts everywhere and if you are really unlucky, they also look for somebody to blame. The latter was not the case this time, but it could might as well have been.
They recently decided to outsource all development, meaning that the sole technical person in the online team, was supposed to move to the new company. Located to begin with in proximity of Copenhagen and one month later moving outside Copenhagen.
It was assumed that I was moving along, me and one of the freelancers I had hired in to help.
After the first shock had settled, I evaluated my options, I went to a few meetings and presentations about the project and it soon became clear that all freelancers/consultants/subcontracters in the development area would be exchanged for people located in India.
So with not much perspective on the gig - I decided to call it quits. I officially informed my contacts of my decision and continued my work on the ongoing projects, so I could finish these and be on my way.
Then my technical contact in the online team resigned.
At the same time I heard about a job at one of the local Perl Monger meetings and later I saw a job ad describing a Perl developer job with the local NIC, DK-Hostmaster.
I had earlier subcontracted to DK-Hostmaster implementing the first version of an EPP integration layer to their system. The project had been interesting to do and it had given me a peek at how they worked and what sort of company they where.
So when I say the job ad and evaluated my current situation I decided to apply, I could always just do an interview to hear what they had to offer.
In all the turmoil from the resignation of the only online technical person, I was contacted whether I would help out. I was somewhat reluctant, at the same time I had nothing else in the pipeline. So I decided to dive into in, attempting to take a lead on the task at hand of knowledge transferring to the new developers in India.
I made an agreement to help out with the knowledge transfer until summer.
I got invited to a second interview with DK-Hostmaster and I got presented with a contract, we had negotiated the salary over the mail and we had met at a reasonable level.
We discussed some more and the job sounded more and more tempting. I would become the primary developer. In charge of the code base, coding guidelines etc. The only negative thing is that it is not a large development team, but I guess I could survive that and they did not even require of me to close my company as long as I did not work for myself on company time or in competition with them.
After some more thinking and evaluation I decided to accept the job offer.
I had informed them that I would not be able to start before after the summer holiday, due to the gentleman agreement with my client (I have just signed the contract yesterday)
So now I am heading for a regular job, the first in years. The job has the following benefits in no particular order:
- Workstation of my choice with operating system of my choice
- Good working hours
- Close to home and my sons kindergarten and nursery (10 minutes by bike)
- A very nice working culture (no overtime and no forced deadlines)
- Technical responsibility
- Influence
- Good salary
So in an attempt to bring some balance back in my iron triangle. I hope to be able to get running again, get some work done on some of my open source projects and not run around like crazy in an attempt to satisfy clients.
So 15th. of August I will start my new job, until then I am just trying to keep things going... I know I will say goodbye to a lot of freedom, but in comparison this would probably be one of the best regular jobs I could land.
The two interesting stories got published at the same time. A fast translation of the topic by me:
“Every 8th. student has problems in elementary school” and “Every 7th. student has problems in elementary school”.
And the same text from both telegrams:
“Den største undersøgelse nogensinde af elever og læreres opfattelse af folkeskolen viser, at op imod 15 procent af eleverne har problemer - hovedsageligt drenge.”
Ok, I will not translate that, but you can dig the figure 15% without any knowledge of Danish.
So if we set up the numbers:
1/8 = 1 * 100 / 8 = 12,5%
1/7 = 1* 100 / 7 = 14.285714286%
According to the journalist behind the telegrams, the percentage is 15. First telegram is clearly closer than the second, but using ordinary rounding rules I only get 14% for 1/7.
Don’t trust anything you read in the newspaper or on the Internet. Actually you should not trust anything in this blog entry, do your own translations and calculations.
While on the phone my eyes fell on my mail client and the spam folder and in particular the count - evil!
It does say that the route is just instructive rules
So I decided to clean my CPAN repository a bit. I am in general saving the latest 2 releases, which mean that the following is going:
All old developer releases:
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.3
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.3
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.3
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.3
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.3
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.3
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.3
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.3
Outdated Workflow releases:
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.1
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.1
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.1
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.1
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.1
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.1
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
$CPAN/authors/id/J/JO/JONASBN/Workflow-0.2
Other outdated releases:
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-D
$CPAN/authors/id/J/JO/JONASBN/Business-O
$CPAN/authors/id/J/JO/JONASBN/Business-O
$CPAN/authors/id/J/JO/JONASBN/Business-O
$CPAN/authors/id/J/JO/JONASBN/Business-O
$CPAN/authors/id/J/JO/JONASBN/Business-O
$CPAN/authors/id/J/JO/JONASBN/Business-O
$CPAN/authors/id/J/JO/JONASBN/Business-O
$CPAN/authors/id/J/JO/JONASBN/Business-O
$CPAN/authors/id/J/JO/JONASBN/Business-O
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Date-Holid
$CPAN/authors/id/J/JO/JONASBN/Games-Bing
$CPAN/authors/id/J/JO/JONASBN/Games-Bing
$CPAN/authors/id/J/JO/JONASBN/Games-Bing
$CPAN/authors/id/J/JO/JONASBN/Games-Bing
$CPAN/authors/id/J/JO/JONASBN/Games-Bing
$CPAN/authors/id/J/JO/JONASBN/Games-Bing
$CPAN/authors/id/J/JO/JONASBN/Games-Bing
$CPAN/authors/id/J/JO/JONASBN/Games-Bing
$CPAN/authors/id/J/JO/JONASBN/Games-Bing
$CPAN/authors/id/J/JO/JONASBN/Module-Inf
$CPAN/authors/id/J/JO/JONASBN/Module-Inf
$CPAN/authors/id/J/JO/JONASBN/Module-Inf
$CPAN/authors/id/J/JO/JONASBN/Module-Inf
$CPAN/authors/id/J/JO/JONASBN/Module-Inf
$CPAN/authors/id/J/JO/JONASBN/Module-Inf
$CPAN/authors/id/J/JO/JONASBN/Test-Timer-0.0
$CPAN/authors/id/J/JO/JONASBN/Test-Timer-0.0
$CPAN/authors/id/J/JO/JONASBN/Test-Timer-0.0
$CPAN/authors/id/J/JO/JONASBN/Test-Timer-0.0
$CPAN/authors/id/J/JO/JONASBN/Test-Timer-0.0
$CPAN/authors/id/J/JO/JONASBN/Test-Timer-0.0
$CPAN/authors/id/J/JO/JONASBN/Test-Timer-0.0
$CPAN/authors/id/J/JO/JONASBN/Test-Timer-0.0
$CPAN/authors/id/J/JO/JONASBN/Test-Timer-0.0
So all of this will soon only be available from backpan, by request from me or from the public code repositories.
Going through all this shows that some of my distributions has had no releases, I guess since last spring cleaning back in January 2006 (spring?).
Date-Holidays-Super
Date-Pregnancy
Module-Template-Setup
Tie-Tools
XML-Conf
I am no so much doing this for the overall size of CPAN, but it does not really make sense to have all these distributions available. They have been updated, some outdated and my support would probably be “please update”.
I hope that the spring cleaning will also address the issue of CPAN testers testing old (broken) releases, I have a few modules where I keep getting test failure reports, even though the failures have been addressed in newer releases.
It did feel good to get this cleaned out, I hope I will be able to find some more idle time, so I can go through some of the TODO files.
We aim for stability, so this is regarded as a bug and we should ensure backwards compatibility.
The release should be on CPAN now. It does however not contain the changes from pre-release 1_33_2, the functionality will not be present until the next pre-release or release until the changes have sunk in and have been merged into trunk.
The bug situation put me in a situation as release manager I have not been before, so I simply followed my intuition, since I do not know what the best practice is.
In a work towards release 1.33, the next public release, we are making developer releases, like 1.33_2 and the never released 1.33_1. Both release where based on the same branch from 1.32.
Then a bug situation occurs and we want to create a bug fix pre-release, so the bug reporter can evaluate the proposed fix.
So I made a branch from 1.32 again and implemented the fix and release it as 1.33_3, even though it does not contain any of the changes from the branch from which 1.33_1 and 1.33_2 was released.
Is this the correct way? - or is there a better way?
This is the first work on the 1.33 release. Please feel free to evaluate and give feedback. Currently it only holds the patch described in RT #18265, the patch implements dynamic loading of configurations.
http://rt.cpan.org/Public/Bug/Display.ht
- bad work-package specification
- bad mocks, simply not thought through
+ good reuse and extension to existing classes and framework
- bad backend, lacking acknowledgement of errors
- - better bottom than top down
- + good collaboration with layout responsible
- - WAY too many hours, the project has taken way too long, this sort of application should take 2-3 weeks max.
+ too many changes to user experience way too late in the project
The application is really nice
We were requested to develop an EPP solution for a client and we had to integrate the EPP solution with the existing legacy system.
+ tracer bullet development
- not complete focus on my side, other things going on at the same time
+ reliable work from colleague
+ good collaboration with client, some misses on meetings etc.
+ good tools for implementing project (Module::Build)
+ open source components (mod_epp)
- delayed delivery due to time constraints on both our but also the clients side
I am quite satisfied with the final result and it was my hope that we would be given the opportunity to extend the solution, since this first release only implements a subset of the EPP protocol.
All in all a very pleasant experience
This has meant spending a lot of hours thinking and evaluating.
I even picked up a book on eXtreme Programming, which was on my shelf of titles to read. XP is a topic I have not looked at for a very long time. I have observed a team doing SCRUM and this has proven quite interesting. I do however like many of the aspects of eXtreme Programming and reading up on XP has proven to be quite energizing.
For the last 4 projects done for my long time client, I have chosen to move the SCM of site, so I am using my own Subversion server. This has shown to be a very good move. I have two hosted Subversion solutions currently one with shelf cloud (version shelf) and another one with Atlassian (JIRA studio).
The first has been magnificent, nice GUI and it has just worked. Setting up and administering a Subversion server might not be the hardest, but I do simply not have the time. For Jira Studio I can only say that support has been magnificent and with the issue tracker (Jira), Wiki (Confluence), Code review (Crucible) and the Greenhopper plugin for project planning, I cannot be more satisfied.
I am currently migrating my old projects to Jira Studio, one at a time, when the need arises. So I will be terminating my account with shelf cloud, but I can only recommend them if Subversion hosting is what you are looking for, I needed more so I am moving on.
The outsourcing business has given me the opportunity, how crazy it might sound, to work in a team again, since one of the laid of people are subcontracting as well and another former employee has joined the ranks of freelance developers, so we are teaming up, looking at new offices and we are meeting regularly to align strategies and plans in order to stay afloat in an economy reacting to a global crisis.
More news on XP, Business, the World and Life later
I find it quite amusing since ISS probably the largest cleaning company and they seem to be everywhere.
But the article had nothing to do with that particular ISS.
- + tracer bullet development, good but not completely accomplished
- - back-end not working properly
- + better specs, not perfect but better
- + outlining and development of test strategy based on previous projects
- - resource allocation, me doing layout
- + using SUPER class and extending it
