|
User since: |
Jul 08, 2003 at 18:02 UTC
(21 years ago) |
Last here: |
Feb 19, 2024 at 15:05 UTC
(41 weeks ago) |
Experience: |
13715
|
Level: | Monsignor (18) |
Writeups: |
1587
|
CPAN ID: | MLX |
Location: | Waukesha, WI, USA |
User's localtime: |
Dec 03, 2024 at 11:24 CST
|
Scratchpad: |
View
|
Member of: |
power users
|
For this user: | Search nodes |
|
About the image
Interesting image taken "up nort'".
About me
My name is Brian T. Wightman. I provide technological solutions.
org-mode
Org-mode is an emacs-lisp module that implements an interface to a file format that is essentially an outline on steroids. The file format is now being processed by languages and editors other than emacs.
I use org-mode as my GTD storage, work notes (bug tracking, project notes and planning, log book, run book), taking minutes for a board I am on, and consulting records. It is flexible enough to provide a framework that can be customized to allow many uses. I don't intend this to be a sales pitch, but am just a really happy customer :-).
There are some monks that use org-mode:
If you wish to be added to this list, please /msg me.
I am collecting a set of org-mode resources as well:
If you know of other resources (especially Perl), please /msg me.
Sidelining
I am currently looking for some sideline contracting positions for about 5-10 hours a week, remote and off hours. See my consulting link for more information.
I have experience with Perl, system administration, security administration, web administration, and other general system maintenance on many types of Unix. I have administered solo small (20-50 machine) Unix shops to working as part of a team in mid to large (100-500+ machine) size shops.
I am amazed, but I am past my 20 year mark at being paid for this type of work.
If interested, please contact me at consulting<at>wightmanfam<dot>org. Note: the address url is tagged, and will change over time as it is discovered by spammers. The displayed address will work for the forseeable future.
Interesting Links
Other Personal Links
Monks I have met in real life
This is a list of monks I have met in real life and where I met them. If you remember meeting me and are not listed here, remind me of where we met.
Blog posts and responses
I will see how long this lasts
Disclaimer
Contrary to some search results, I do not have a livejournal profile. That midlifexis is an unfortunate name collision, and appears to be quite a different person. The only valid location for this moniker is here on perlmonks This moniker is valid on sites listed in my Other Personal Links section.
Posts by MidLifeXis
|
RFC: (Do Not) Modify the System Perl
in Meditations
9 direct replies — Read more / Contribute
|
by MidLifeXis
on Oct 16, 2015 at 14:39
|
|
Update: Excellent points made in responses. A rewrite is in the works. Keep them coming.
Perhaps this is a tutorial, or perhaps something that just belongs long term in Meditations, but my intent with this node is to document the arguments related to modifying the system's Perl installation, so that I don't have to lay out the argument every time it comes up in SoPW. There are some pro, and some con, but it seems to be, in my experience, that "Can't touch this", if given the choice, is the correct path to take.
Some of the previous comments I have made on this topic can be found here: SuperSearch Preload
So, without further ado, here are some arguments in favor of installing your own Perl (in no particular order):
- Modifying the system Perl can break the OS.
- Updating the OS can change the underlying Perl, breaking your application.
- You don't necessarily have control over the system's Perl.
- Updating the system's perl for application's needs can go against another application's needs.
- The system's Perl may not be complete.
- By packaging Perl with your application stack, you control the installed modules and toolchain.
- It is easier to target a single Perl version than anything you might find on the OS.
- Policy may disallow installing a "necessary" module on the system's Perl.
- Your installed / updated CPAN modules may be overwritten (and downgraded) by OS updates. - Corion
- You are (safely) limited to the module versions provided in packages by your vendor - Corion
There are also some cons to installing your own Perl:
- Your application distribution now requires or includes a separate Perl distribution.
- Your packaging requirements are now more complex.
In summary, unless you are writing an OS-level tool specifically for this platform, install a Perl version specifically for your own application's runtime stack.
Anything else? (ed: updates tagged with author)
|
CPAN Testers is back
in Perl News
No replies — Read more | Post response
|
by MidLifeXis
on Sep 18, 2015 at 15:44
|
|
|
BrewCity PM: Fun with RapidApp by VANSTYN
in Perl News
No replies — Read more | Post response
|
by MidLifeXis
on Apr 16, 2015 at 08:52
|
|
|
BrewCity Perlmongers meeting: 2015-Mar-19, 7:00 pm (GMT-0500)
in Perl News
1 direct reply — Read more / Contribute
|
by MidLifeXis
on Mar 16, 2015 at 13:44
|
|
Miscellaneous Debris by fREW
The Milwaukee PerlMongers chapter meeting for March is on Thursday the 19th at 7:00 pm, Milwaukkee time. The meeting and presentation will be broadcast on the Brew City Perlmongers G+ page. See the Meetup announcement for more details.
|
Named captures or positional variables
in Seekers of Perl Wisdom
4 direct replies — Read more / Contribute
|
by MidLifeXis
on Dec 10, 2014 at 14:44
|
|
I asked a question on CB today if the benefits of using named capture groups outweigh the overhead, especially from a maintenance view. Given the varied answers and opinions, as well as encouragement to make a post for a wider range of comments, I am posting the question here. Specifically, I am breaking an almost free form logfile format into tokens (FlexLM, for those that are interested). Each line in the log file may be in one of many different formats.
The two general forms I am looking at are...
my $re_foo = qr{
...
(?<type>
...
)
...
(?<name1>
...
)
}x;
my $re_bar = qr{
...
(?<name2>
...
)
...
(?<type>
...
)
...
}x;
my $re_all = qr{$re_foo|$re_bar};
if ( $data =~ $re_all ) {
return { %+ };
}
...
vs
my $re_foo = qr{
...
( # type
...
)
...
( # name1
...
)
}x;
my $re_bar = qr{
...
( # name2
...
)
...
( # type
...
)
...
}x;
if ( $data =~ $re_foo ) {
return { type => $1, name1 => $2 };
}
elsif ( $data =~ $re_bar ) {
return { type => $2, name2 => $1 };
}
...
The first seems to me to be much more maintainable, even if performance is impacted a bit. What other opinions, comments, or concerns are there about this construct?
|
BrewCity Mongers Meeting (2014/10/16 18:00-21:00 GMT-0500) - Discover Editors
in Perl News
1 direct reply — Read more / Contribute
|
by MidLifeXis
on Oct 16, 2014 at 09:00
|
|
The BrewCity Mongers (Milwaukee.pm) is having its monthly meeting tonight from 6:00pm until 9:00pm, Milwaukee time. For more details, and a link to a google broadcast, see the meetup page.
|
RFC: interface for a DBD::Proxy-like module client-side DSN
in Meditations
No replies — Read more | Post response
|
by MidLifeXis
on Aug 14, 2014 at 09:22
|
|
I made mention of this in the CB the other day, but didn't get many responses, so I thought I would ask it here to perhaps get a wider audience and set of responses.
I am modifying a copy of DBD::Proxy/DBI::ProxyServer so that instead of specifying the entire server-side DSN on the client side, you instead specify a known name of a handle to a configured DSN on the server side. Using this and implementing the sql section of the configuration to another set of known queries would allow the client to use a DBI compliant data source without needing to have the server-side implementation details available. I am also looking to update the connection / user / query definition sections to make them more able to be isolated from one another.
- Does a client-side DSN along the lines of dbi:Router:hostname=$hostname;port=$port;dsn=dbi:router:$remotename seem like a reasonable interface? [clarification: $hostname and $port are for connecting to the proxy / routing server, not the database -- that is fully configured on the routing server] Is there something (currently) better to base this on than DBD::Proxy/DBI::ProxyServer?
- Does the name seem sensible?
- Should I just try to incorporate this directly into the DBD::Proxy core itself?
- Any other thoughts / previously invented wheels / ideas?
The major use case I have for this is to standardize access to all of the little bits of information I have to use for my applications which currently exist in different data stores (CSV/TSV, SQLite, ldap, ...) in order to migrate them into a more manageable setup without impacting the application code. This type of configuration would also allow for the mockup of a testing set of data, migration to different platforms, ...
Updates
- pgbouncer was mentioned as a similar tool
- Added description of my use case
- Added a clarification of what the host/port refer to
|
Perl.org NOC notice for PAUSE (back up again)
in Perl News
1 direct reply — Read more / Contribute
|
by MidLifeXis
on Jan 09, 2014 at 08:24
|
|
Since we had a few questions in the CB yesterday along the lines of "Is PAUSE down?", I was hoping to see an update from the larger Perl community as to what is going on. They did not fail.
It looks like a set of hard drives failed on the system hosting PAUSE. Work is being done to get this back up and running. See also:
If there are additional workarounds or status notes, please add a comment or /msg me and I will add it to the list.
Update (2014/01/10 07:00 GMT -0500): Added Pinto workaround link. Status: http://pause.perl.org, http://cpan.perl.org still down.
Update (2014/01/13 07:35 GMT -0500): As of 2014/01/11 11:04 GMT -0500, the machine hosting PAUSE and cpan.perl.org are is back up and running.
|
Milwaukee.pm monthly meeting on Google Hangouts (tonight: 18:00 GMT -0600)
in Perl News
1 direct reply — Read more / Contribute
|
by MidLifeXis
on Dec 19, 2013 at 13:20
|
|
Brew City Mongers monthly meeting will feature a discussion by
Rob Hoelz titled "Perl Power Tools". A Google Hangout has been configured to allow for virtual participation.
The presentation starts 18:30ish with a PerlJam session (a short, possibly beginning Perl topic yet TBD).
This is the first time Milwaukee.pm (a fairly new PM group) is providing a Google Hangout for the meeting, so be gentle :-).
|
Felling a tree JAPH
in Obfuscated code
2 direct replies — Read more / Contribute
|
by MidLifeXis
on Aug 30, 2013 at 10:28
|
|
Still not a great JAPH, and it exceeds 4x79, but it is more obfuscated than yesterday's.
# Cutting down a tree
$t=t->p;$t->g;$t->f;sub t::p{@n=map{x($_)}'Just another Perl hacker,'=
+~m/(.)/g;
bless{n=>\@n},$_[0]}sub t::g{$_[0]->{t}=$_[0]->f(0,$#{$_[0]->{n}});$_[
+0]->{n}=1
;$_[0]}sub t::f{($a,$b,$e)=@_;$m=int(($b+$e)/2);$f=$_[0]->{n}[$m];$l=$
+_[0]->f(
$b,$m-1)if$b<$m;$r=$_[0]->f($m+1,$e)if$m<$e;bless [$l,$f,$r],'f'}sub t
+::f{$_[0]
->{t}=1}sub x{bless \$_[0],"x"}sub x::DESTROY{print${$_[0]}}sub f::DES
+TROY{$_[0
]->[$_]=1 for(0..2)}
|
|
|
|