Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.
Saturday, March 02, 2024
Safety shouldn't be opt-in
Many years ago, when I was starting to have my first experiences with Functional Programming (thanks to learning the amazing F# language), I discovered what seemed to be a problem that was not really a concern in the OOP world that I was leaving behind: stack overflows caused by stack recursion.
I was puzzled: from one point of view, mutability is dangerous and has to be avoided; however, if you avoid it in a certain way by using recursion, you might hit this other kind of problem. Sure, an exception at runtime is much better than the typical problems associated with mutability (race conditions or heisenbugs, which are very hard to debug and fix), however there was no way of making sure that you don't hit this problem in your recursion-based algorithms unless you made sure that... you use TailCall-friendly recursion.
Huh? What in the world does TailCall-friendly recursion means? When I first tried to wrap my head around this concept, it was hard, and to this day it is still is. But the real problem I saw is that there was no deterministic way to make sure that your recursive algorithm that you tried to make TailCall-friendly, is indeed TailCall-friendly. That's why I thought: wouldn't it be nice that the compiler warns me when I didn't succeed in making this algorithm TailCall-friendly? And that's why I filed an enhancement request in the proper channel for that which, at the time, used to be UserVoice.
Several weeks or months later, I discovered that my enhancement request was the most upvoted of all?! Maybe because the F# team had recently moved to UserVoice and I had been lucky to be one of the first people to file a ticket, which subsequently got a lot of views? I don't know, but I was happy. And the team agreed to implement it "in principle" (as far as I remember).
Some years passed, and I started getting better and better at F#, to the point that I started my own opensource project using it. But in the back of my mind I was still concerned about this downside that I had discovered when delving for the first time in Functional Programming. So I looked for the UserVoice ticket to see if it had been finally implemented: sadly, the F# team had moved out from UserVoice to a different way of tracking enhancement requests, and therefore, all the upvotes of it had vanished, and it was no longer "the most upvoted". Also, it hadn't been marked as fixed or actioned at all. There were some people talking about it and proposing ways of doing it, but nothing had really been set in stone.
Until last December! It turns out someone had finally worked on it and contributed it upstream. I was very happy and delighted that you can finally protect yourself at compile-time from this pitfall. However, when I saw how the feature can be used, I was a bit heart-broken. The initial feature request was titled along the lines of "Emit a compiler warning when a recursive algorithm is not tail-recursive", then probably Microsoft renamed it to "Enable a compiler-warning when...". Then I thought: ah, they are going to make it opt-in at the project level, probably. Boo! They didn't make it opt-in at the project level, not even at the module level! They made it opt-in at the function level! :-(
Oh well, it's a step in the right direction for sure. But don't we all think that SAFETY SHOULDN'T BE OPT-IN? Especially as F# developers, because many of us moved away from C# because F# has safer defaults, for example: if you want to use mutability, you can still do it, but then you need to use a keyword to opt-in: `mutable` (not like in C# in which safety is opt-in, e.g. the keyword `readonly`).
So then... I decided to do something about it.
If you're a lover of static typing, you rather prefer to get compiler errors than runtime errors. And if you like compiler errors, there's a chance that you also like warnings. And if you like warnings, there's a chance that you like to turn on "warnings as errors". And if you like warnings as errors, there's a chance that you also normally like to go the extra mile: you like linters and static analysis tools. And so, if you're already using a tool like this, wouldn't you expect them to give you extra protection? And wouldn't you want that the strongest protection layers that these tools provide are enabled by default, not opt-in? Enter EnsureTailCallDiagnosticsInRecursiveFunctions!!: a new FSharpLint rule that my team has implemented which will not shut up until you have marked all your recursive functions with the `[<TailCall>]` attribute, to make sure you are properly warned when you're not protected from potential stack overflows.
I merged the PR that implemented this rule this week, and made a release, 0.24.2, so that you can already adopt it in your project, and be protected by default (because the rule is enabled by default). And so if you're using FSharpLint, safety is not opt-in anymore, it is default. And you can opt-out from safety by disabling this rule (completely, or in a case-by-case basis) in case you need it.
Labels: General, Ingenieria, Programacion
Saturday, February 08, 2020
Xamarin forks and whatnots
Busy days in geewallet world! I just released version 0.4.2.198 which brings some interesting fixes, but I wanted to talk about the internal work that had to be done for each of them, in case you're interested.
- In Linux(GTK), cold storage mode when pairing was broken, because the absence of internet connection was not being detected properly. The bug was in a 3rd-party nuget library we were using: Xam.Plugin.Connectivity. But we couldn't migrate to Xamarin.Essentials for this feature because Xamarin.Essentials lacks support for some platforms that we already supported (not officially, but we know geewallet worked on them even if we haven't released binaries/packages for all of them yet). The solution? We forked Xamarin.Essentials to include support for these platforms (macOS and Linux), fixed the bug in our fork, and published our fork in nuget under the name `DotNetEssentials`. Whenever Xamarin.Essentials starts supporting these platforms, we will stop using our fork.
- The clipboard functionality in geewallet depended on another 3rd-party nuget library: Xamarin.Plugins.Clipboard. The GTK bits of this were actually contributed by me to their github repository as a Pull Request some time ago, so we just packaged the same code to include it in our new DotNetEssentials fork. One dependency less to care about!
- Xamarin.Forms had a strange bug that caused some buttons sometimes to not be re-enabled. This bug has been fixed by one of our developers and its fix was included in the new pre-release of Xamarin.Forms 4.5, so we have upgraded geewallet to use this new version instead of v4.3.
PS: Apologies if the previous blogpost or this one shows up in planets again, as it might be a side-effect of updating its links to point to the new git repo!
Labels: CSharp, General, Ingenieria, Miscelanea, Mono, Programacion, SoftwareLibre, Xamarin
Sunday, January 05, 2020
Introducing geewallet
Version 0.4.2.187 of geewallet has just been published to the snap store! You can install it by looking for its name in the store or by installing it from the command line with `snap install geewallet`. It features a very simplistic and minimalistic UI/UX. Nothing very fancy, especially because it has a single codebase that targets many (potential) platforms, e.g. you can also find it in the Android App Store.
What was my motivation to create geewallet in the first place, around 2 years ago? Well, I was very excited about the “global computing platform” that Ethereum was promising. At the time, I thought it would be like the best replacement of Namecoin: decentralised naming system, but not just focusing on this aspect, but just bringing Turing-completeness so that you can build whatever you want on top of it, not just a key-value store. So then, I got ahold of some ethers to play with the platform. But by then, I didn’t find any wallet that I liked, especially when considering security. Most people were copy+pasting their private keys into a website (!) called MyEtherWallet. Not only this idea was terrifying (since you had to trust not just the security skills of the sysadmin who was in charge of the domain&server, but also that the developers of the software don’t turn rogue…), it was even worse than that, it was worse than using a normal hot wallet. And what I wanted was actually a cold wallet, a wallet that could run in an offline device, to make sure hacking it would be impossible (not faraday-cage-impossible, but reasonably impossible).
So there I did it, I created my own wallet.
After some weeks, I added bitcoin support on it thanks to the library NBitcoin (good work Nicholas!). After some months, I added a cross-platform UI besides the first archaic command-line frontend. These days it looks like this:
What was my motivation to make geewallet a brain wallet? Well, at the time (and maybe nowadays too, before I unveil this project at least), the only decent brain wallet out there that seemed sufficiently secure (against brute force attacks) was WarpWallet, from the Keybase company. If you don’t believe in their approach, they even have placed a bounty in a decently small passphrase (so if you ever think that this kind of wallet would be hacked, you would be certainly safe to think that any cracker would target this bounty first, before thinking of you). The worst of it, again, was that to be able to use it you had again to use a web interface, so you had the double-trust problem again. Now geewallet brings the same WarpWallet seed generation algorithm (backed by unit tests of course) but on a desktop/mobile approach, so that you can own the hardware where the seed is generated. No need to write anymore long seeds of random words in pieces of paper: your mind is the limit! (And of course geewallet will warn the user in case the passphrase is too short and simple: it even detects if all the words belong to the dictionary, to deter low entropy, from the human perspective.)
Why did I add support for Litecoin and Ethereum Classic to the wallet? First, let me tell you that bitcoin and ethereum, as technological innovations and network effects, are very difficult to beat. And in fact, I’m not a fan of the proliferation of dubious portrayed awesome new coins/tokens that claim to be as efficient and scalable as these first two. They would need not only to beat the network effect when it comes to users, but also developers (all the best cryptographers are working in Bitcoin and Ethereum technologies). However, Litecoin and Ethereum-Classic are so similar to Bitcoin and Ethereum, respectively, that adding support for them was less than a day’s work. And they are not completely irrelevant: Litecoin may bring zero-knowledge proofs in an upcoming update soon (plus, its fees are lower today, so it’s an alternative cheaper testnet with real value); and Ethereum-Classic has some inherent characteristics that may make it more decentralised than Ethereum in the long run (governance not following any cult of personality, plus it will remain as a Turing-complete platform on top of Proof Of Work, instead of switching to Proof of Stake; to understand why this is important, I recommend you to watch this video).
Another good reason of why I started something like this from scratch is because I wanted to use F# in a real open source project. I had been playing with it for a personal (private) project 2 years before starting this one, so I wanted to show the world that you can build a decent desktop app with simple and not too opinionated/academic functional programming. It reuses all the power of the .NET platform: you get debuggers, you can target mobile devices, you get immutability by default; all three in one, in this decade, at last. (BTW, everything is written in F#, even the build scripts.)
What’s the roadmap of geewallet? The most important topics I want to cover shortly are three:
- Make it even more user friendly: blockchain addresses are akin to the numeric IP addresses of the early 80s when DNS still didn’t exist. We plan to use either ENS or IPNS or BNS or OpenCAP so that people can identify recipients much more easily.
- Implement Layer2 technologies: we’re already past the proof of concept phase. We have branches that can open channels. The promise of these technologies is instantaneous transactions (no waits!) and ridiculous (if not free) fees.
- Switch the GTK Xamarin.Forms driver to work with the new “GtkSharp” binding under the hood, which doesn’t require glue libraries. (I’ve had quite a few nightmares with native dependencies/libs when building the sandboxed snap package!)
With less priority:
- Integrate with some Rust projects: MimbleWimble(Grin) lib, the distributed COMIT project for trustless atomic swaps, or other Layer2-related ones such as rust-lightning.
- Cryptography work: threshold keys or deniable encryption (think "duress" passwords).
- NFC support (find recipients without QR codes!).
- Tizen support (watches!).
- Acceptance testing via UI Selenium tests (look up the Uno Platform).
Areas where I would love contributions from the community:
- Flatpak support: unfortunately I haven’t had time to look at this sandboxing technology, but it shouldn’t be too hard to do, especially considering that there’s already a Mono-based project that supports it: SparkleShare.
- Ubuntu packaging: there’s a patch blocked on some Ubuntu bug that makes the wallet (or any .NET app these days, as it affects the .NET package manager: nuget) not build in Ubuntu 19.10. If this patch is not merged soon, the next LTS of Ubuntu will have this bug :( As far as I understand, what needs to be solved is this issue so that the latest hotfixes are bundled. (BTW I have to thank Timotheus Pokorra, the person in charge to package Mono in Fedora, for his help on this matter so far.)
- GNOME community: I’m in search for a home for this project. I don’t like that it lives in my GitLab username, because it’s not easy to find. One of the reasons I’ve used GitLab is because I love the fact that being open source, many communities are adopting this infrastructure, like Debian and GNOME. That’s why I’ve used as a bug tracker, for merge requests and to run CI jobs. This means that it should be easy to migrate to GNOME’s GitLab, isn’t it? There are unmaintained projects (e.g. banshee, which I couldn’t continue maintaining due to changes in life priorities...) already hosted there, so maybe it’s not much to ask if I could host a maintained one? It's probably the first Gtk-based wallet out there.
And just in case I wasn't clear:
- Please don’t ask me to add support for your favourite %coin% or <token>.
- If you want to contribute, don’t ask me what to work on, just think of your personal itch you want to scratch and discuss it with me filing a GitLab issue. If you’re a C# developer, I wrote a quick F# tutorial for you.
- Thanks for reading up until here! It’s my pleasure to write about this project.
I'm excited about the world of private-key management. I think we can do much better than what we have today: most people think of hardware wallets to be unhackable or cold storage, but most of them are used via USB or Bluetooth! Which means they are not actually cold storage, so software wallets with offline-support (also called air-gapped) are more secure! I think that eventually these tools will even merge with other ubiquitous tools with which we’re more familiar today: password managers!
You can follow the project on twitter (yes I promise I will start using this platform to publish updates).
PS: If you're still not convinced about these technologies or if you didn't understand that PoW video I posted earlier, I recommend you to go back to basics by watching this other video produced by a mathematician educator which explains it really well.
PS: If you're still not convinced about these technologies or if you didn't understand that PoW video I posted earlier, I recommend you to go back to basics by watching this other video produced by a mathematician educator which explains it really well.
PS II: Apologies if this blogpost shows up in planets again, as it might be a side-effect of updating it to fix broken links or typos.
Labels: CSharp, General, Gnome, Ingenieria, Miscelanea, Mono, Programacion, Seguridad, SoftwareLibre, Xamarin
Wednesday, January 23, 2019
WORA-WNLF
I started my career writing web applications. I had struggles with PHP web-frameworks, javascript libraries, and rendering differences (CSS and non-CSS glitches) across browsers. After leaving that world, I started focusing more on the backend side of things, fleeing from the frontend camp (mainly actually just scared of that abomination that was javascript; because, in my spare time, I still did things with frontends: I hacked on a GTK media player called Banshee and a GTK chat app called Smuxi).
So there you had me: a backend dev by day, desktop dev by night. But in the GTK world I had similar struggles as the ones I had as a frontend dev when the browsers wouldn’t behave in the same way. I’m talking about GTK bugs in other non-Linux OSs, i.e. Mac and Windows.
See, I wanted to bring a desktop app to the masses, but these problems (and others of different kinds) prevented me to do it. And while all this was happening, another major shift was happening as well: desktop environments were fading while mobile (and not so mobile: tablets!) platforms were rising in usage. This meant yet more platforms that I wished GTK supported. As I’m not a C language expert (nor I wanted to be), I kept googling for the terms “gtk” and “android” or “gtk” and “iOS”, to see if some hacker put something together that I could use. But that day never happened.
Plus, I started noticing a trend: big companies with important mobile apps started to stop using HTML5 within their apps in favour of native apps, mainly chasing the “native look & feel”. This meant, clearly, that even if someone cooked a hack that made gtk+ run in Android, it would still feel foreign, and nobody would dare to use it.
So I started to become a fan of abstraction layers that were a common denominator of different native toolkits and kept their native look&feel. For example, XWT, the widget toolkit that Mono uses in MonoDevelop to target all 3 toolkits depending on the platform: Cocoa (on macOS), Gtk (on Linux) and WPF (on Windows). Pretty cool hack if you ask me. But using this would contradict my desires of using a toolkit that would already support Android!
And there it was Xamarin.Forms, an abstraction layer between iOS, Android and WindowsPhone, but that didn’t support desktops. Plus, at the time, Xamarin was proprietary (and I didn’t want to get out of my open source world). It was a big dilemma.
But then, some years passed, and many events happened around Xamarin.Forms:
- Xamarin (the company) was bought by Microsoft and, at the same time, Xamarin (the product) was open sourced.
- Xamarin.Forms is opensource now (TBH not sure if it was proprietary before, or it was always opensource).
- Xamarin.Forms started supporting macOS and Windows UWP.
- Xamarin.Forms 3.0 included support for GTK and WPF.
So that was the last straw that made me switch completely all my desktop efforts toward Xamarin.Forms. Not only I can still target Linux+GTK (my favorite platform), I can also make my apps run in mobile platforms, and desktop OSs that most people use. So both my niche and mainstream covered! But this is not the end: Xamarin.Forms has been recently ported to Tizen too! (A Linux-based OS used by Samsung in SmartTVs and watches.)
Now let me ask you something. Do you know of any graphical toolkit that allows you to target 6 different platforms with the same codebase? I repeat: Linux(GTK), Windows(UWP/WPF), macOS, iOS, Android, Tizen. The old Java saying is finally here! (but for the frontend side): “write once, run anywhere” (WORA) to which I add “with native look’n’feel” (WORA-WNLF)
If you want to know who is the hero that made the GTK driver of Xamarin.Forms, follow @jsuarezruiz which BTW has been recently hired by Microsoft to work on their non-Windows IDE ;-)
PS: If you like .NET and GTK, my employer is also hiring! (remote positions might be available too) ping me
Labels: CSharp, General, Gnome, Ingenieria, Mono, Programacion, SoftwareLibre, Xamarin
Wednesday, September 08, 2010
Version Tolerant Serialization with Mono
(Zoot Woman - Lonely By Your Syde)
During the last months I've kept working {with|on} Mono, but not working for Novell anymore.
Today I'm proud to blog about a bit of work I've done on Mono towards a better Binary Serialization experience:
- mono-api-info command now can output ABI instead of API if you append the flag --abi. It has been useful for us in LindenLab while working on binary serialization compatibility between versions (already upstream!, so will be available in Mono v2.8, even with a new man page).
If you ever wondered why your .NET code is no longer capable of deserializing some old binary object you had in your servers, instead of fixing the problem in a case-by-case basis, you can now see the whole picture by just diffing the output of mono-api-info --abi from your current and old codebase! A small TODO that I haven't completed yet is to deal with automatic properties (because we still don't use them) so that would be an exercise for the reader! - Fix for upstream Mono to act as .NET in regards to Version Tolerant Serialization, a patch to which I have just added a lot more unit tests (soon to be pushed hopefully).
You can see the patch of this quite old mono bug here. Disclaimer: to be honest you will only need the previous --abi tool if you use a Mono version prior this fix, because from my testing VTS in MS.NET works as if every new field had an [OptionalField] attached! (At least the BinaryFormatter, the TODO here for the reader is to test the SoapFormatter ;) )
On a totally unrelated note: kudos to the MonoDevelop team for making such a great releases lately (and fixing the bugs I report so promptly). I've been testing it the last months on Windows and I can say it's a great experience to see your favorite IDE working cross-platform and making you not depend on VS anymore if you need to work on Windows from time to time (I know the Express versions are free, and are great! but they do not support plugins :( ). BTW, I've been lately experimenting with the C language support in this IDE, and have had some problems, but the real culprit seems to lay behind some wierd behaviour of my gdb in opensuse. Taking advantage that I'm in opensuse planet, can I do a couple of lazyweb requests?:
a) If you're quite familiar with gdb, can you take a look at these 2 bugs in case it rings any bell for you? BNC#588175, BNC#459274
b) Can you try to reproduce those bugs in openSUSE 11.3? (I haven't migrated yet from 11.2 because I fear about the HALlessness of it :) )
PS: Wondered why the video on the top? Well, I like the trend that some people have about posting random photos in their blog posts even when they may be completely unrelated, but in my case I love music so I figured this would suit better. Of course I would rather embed a WebM video or, even better, something that can preview a song (without video) in a "normally-lower-quality-than-what-you-can-buy" way, so if you have any hints, those are welcome! I especially mention the latter in this case because the Album version of the song above is much much better (synth pop FTW!).
UPDATE 28-AUG-2012: Found a video-less alternative to youtube for embedding songs! It is GoEar.
Labels: CSharp, General, Ingenieria, Mono, Programacion, SoftwareLibre
Tuesday, July 06, 2010
Mono? What?
Really sad to read this:
.NET Culture Shock: Why .NET Adoption Lags Among Startups
Especially sad to find that Mono is not mentioned in the article.
Especially super sad to find that Mono is mentioned in the comments, but in a negative way.
Hey Mono community, help me reply all this nonsense.
.NET Culture Shock: Why .NET Adoption Lags Among Startups
Especially sad to find that Mono is not mentioned in the article.
Especially super sad to find that Mono is mentioned in the comments, but in a negative way.
Hey Mono community, help me reply all this nonsense.
Labels: CSharp, General, Ingenieria, Mono, Programacion, SoftwareLibre, WebDev
Monday, March 30, 2009
I14Y happens
Some years ago, I started to get familiarized with abbreviations like 'l10n', 'i18n' when I started contributing to the translation efforts of Mozilla & Firefox under the NAVE Project.
Some months later I came to know the new term 'a11y', and I started to see it in a lot of places. By that time, I only associated it with the web development world. Terms like "Unobstrusive JavaScript" were very related to it (and I even created an "AJAXy" library called AMUSE for this purpose).
Now let's talk about the next one: I14Y. This concept is present when things like this happen: "I can open an (Microsoft's)OpenXML file with some (Novell's) edition of (Sun's)OpenOffice". Or even more weird things: "I can manage my (Apple's)IPod thanks to a (Microsoft's).NET-powered application called (Novell's)Banshee". Or even more awesome ones: "I can use (Sun?'s)Orca screen reader to control my (Microsoft's)Windows.Forms-powered applications in my (Novell's)SUSE Linux Box!".
So, yeah, we made it! Along with the awesome releases of Mono 2.4 and MonoDevelop 2.0.
Now, guess what's the word?
Some months later I came to know the new term 'a11y', and I started to see it in a lot of places. By that time, I only associated it with the web development world. Terms like "Unobstrusive JavaScript" were very related to it (and I even created an "AJAXy" library called AMUSE for this purpose).
Now let's talk about the next one: I14Y. This concept is present when things like this happen: "I can open an (Microsoft's)OpenXML file with some (Novell's) edition of (Sun's)OpenOffice". Or even more weird things: "I can manage my (Apple's)IPod thanks to a (Microsoft's).NET-powered application called (Novell's)Banshee". Or even more awesome ones: "I can use (Sun?'s)Orca screen reader to control my (Microsoft's)Windows.Forms-powered applications in my (Novell's)SUSE Linux Box!".
So, yeah, we made it! Along with the awesome releases of Mono 2.4 and MonoDevelop 2.0.
Now, guess what's the word?
Labels: CSharp, General, Ingenieria, Mono, Mozilla, Programacion, SoftwareLibre, WebDev
Saturday, May 10, 2008
A new community devolopment model?
Long story
(Go to the short story if you're too lazy to read a lot.)Some time ago I wrote about the usual confusion between the terms "commercial" and "propietary". FLOSS is commercial software because it's not only driven by the generosity of some developers with their spare time. A FLOSS developer can be paid by a software company, either by being employed (the most common case currently) or either by a consultancy/bounty basis. And there are still even open source companies which still indirectly refer to FLOSS as non-commercial when they compare both most popular development models nowadays by saying "open source VS commercial software".
And why the bounty system is not so popular? Well, because:
1) It's very project-driven: bounties are usually published in means very related to the project. This can be considered an advantage because only motivated/interested developers will apply, but sometimes the project is too small, too recent or not very popular, or with a lot of similar projects around.
2) There's no strong system to manage the bounty in respect to requirements, secure payment, trust system between parts, etc.
3) Many people don't advocate for it (or they advocate for a bounty system that works as a task exchange without money intervention: I fix this for you if you fix this for me) because, we know, one of the reasons of the excellence of free software is because developers love what they do without rewards. (But IMHO one of the big downsides is also because there are also important tasks in a project that nobody likes to do. Besides, I think people tend to spend less spare time on free software as their age grows.)
An exception to the 1st item could be bountycounty.org: a site that tries to announce bounties from free software projects. However, it seems to be an initiative that hasn't got much audience (the last bounty is 2 years old), either because the people that offer bounties forget to notify to this system, or, maybe because in the end the bounty development model doesn't work in FLOSS?
Well, I don't think this is the case, because there's a bounty system that is succeeding, and which is also an exception to the (2) item of the above list: Google Summer of Code.
However, GSoC has the following disadvantages to be "complete" for this matter:
a) Only students can apply.
b) All projects happen in the same time-frame and have the same duration (a summer).
c) All bounties are the same for each developer.
d) A concrete company controls all the process (because, it's true, they put the money).
But we need something similar to GSoC (similar in the "It Works" aspect) and that saves these problems and is not a mere "announcement" site like BountyCounty.org.
Some initiatives have appeared that tried to solve these situation: BountySource.com and SourceForge.net marketplace. The common problem to both is that they try to solve it by attracting the developers to host their projects, so this causes big and mature projects not to apply (because they have currently good hosting solutions, or are self-hosted, like Mozilla projects for instance).
One of the ideas is to implement a bounty system in our bug tracking system software, like Bugzilla. If I had time and liked Perl more, I would try to contribute something for it. Maybe we're in the chicken-egg problem here: we need a bounty system for that task.
Surprisingly, there's already a general purpose web-based service for this task: RentACoder.com. But I haven't seen any free software projects using it, because it seems very focused on propietary developments.
And then it happened: Some weeks ago a new FLOSS-oriented service was born: FOSS Factory. I wanted to start using it by publishing some mini-bounties (which hopefully would grow if other people are interested, similarly to voting systems in Bug Tracking software), but I got disappointed when even the project creation had a cost. But yesterday I received this e-mail:
Andres G. Aragoneses,
Thanks so much for your interest in FOSS Factory! As one of our early adopters, I wanted to keep you in the loop on two very important developments.
First, in response to user feedback, we've removed all costs for creating FOSS Factory projects! Instead, we now charge a 5% transaction fee on payouts. This aligns our interests with yours by ensuring that we will only make money if your projects succeed. It also enables developers to post their own projects without having to spend money.
Second, we recently released our website source code under a FOSS license. You can now download the code from http://www.fossfactory.org/get-source.php. Our primary reason for doing this was so that we could take advantage of our own system to help improve the site. In case you're interested, we've already posted a few bounties for improvements that we haven't had time to implement ourselves: http://www.fossfactory.org/project.php?p=p30&tab=subprojects. Please feel free to participate.
If you have any questions or concerns, please either reply to this message, or email me directly at jjgignac {at} fossfactory {dot} org. Your feedback is very important to us!
Sincerely,
John-Paul Gignac
President and Founder
FOSS Factory Inc.
Unfortunately, there's a 5% transaction charge for each bounty, but hey, we need to support their service! Also, the software is PHP based, so I won't likely spend time on improving it (you know, I already fled from PHP and Perl some years ago ;) ).
But I like the initiative and I'll start to publish the bugs/features I consider interesting to have, but have no time/interest to hack on. Here are the first ones (take in account that, if every voter of the bug payed 10$, the bounty would be enough attractive for a developer I guess, because they are not very complicated):
- Thunderbird/Seamonkey feature Auto-watch threads you've posted to (21 votes)
- Thunderbird/Seamonkey regression Allow edit of unsent message (Unsent folder messages should open to a compose window when double click) (26 votes)
- Bugzilla's feature (or fix for highly confusing workflow for newcomers) Move all bug activity onto main bug screen (17 votes)
- Banshee's feature (currently handled by an outdated addin AFAIK) Banshee needs a way to cleanup (remove stale tracks) (reporter+4CC; no voting system in BGO)
- Banshee's feature (patch proposed but I guess someone should make it apply to trunk) [Patch] Automatically scan music folders for new songs (reporter+6CC; no voting system in BGO)
- Gnome's bug (someone wrote a patch but not sure if it will finally make it for 2.24...) The ``Replace File'' dialog should display the two file sizes, times, etc. (reporter+23CC; no voting system in BGO)
- Monsoon's crazy feature (maybe implies the creation of a new Gtk widget) When the option "Minimize to notification area on close" is not enabled, we should have a new widget on the title bar for that action (just me)
- Real fix for Mono's issue (because we already have a workaround) System.Windows.Forms dependency on GTK makes code to crash if it uses ATK# and GTK_MODULES contains 'atk-bridge'
The last of the issues affected our project until we found a workaround overriding environment variables. If we reach our milestones properly and nobody has fixed it at that time, we could have a try! Now we still have tons of work which Calvin and the team have perfectly outlined. Unfortunately I haven't helped in this doc effort because I was busy debugging the issues I mentioned in my last post, which turned out to be an invalid bug (but at least gave me an idea for a Gendarme Rule) and a GAPI parser bug that Mike fixed) and because on thursday afternoon I was affected by some small rock ;) and probably was the cause of me trying to debug something I didn't correctly updated on Friday (and maybe because of our dumb deployment methodology that Mike has already blamed). Well, I'll talk about this in a later entry...
Short story
Maybe this day will be remembered in the Free Software community as the day in which a first software draft is presented in order to fill some awesome ideas from devs like Nat Friedman about a general-purpose bounty system:FOSS Factory
Especially interesing is their reasonings for its creation.
Update 12-AUG-2009: Another interesting service I found (while reading the comments of this blog entry) is COfundOS.org
Update 10-MAY-2010: Wow, it seems that a new project was born, which is getting a lot of press and support, to fund projects (but any kind of projects, not only software). It's called Kickstart and it's key feature is that people can pledge for a project but if it doesn't reach the amount required, the people are never charged. I wonder if there should be an option to have projects not have a deadline (more suitable to bugs in bugzillas ;) ). And after reading the FAQ I still cannot figure out how they judge if a project was successfull...
Update 16-SEP-2010: Over the last months I've been still thinking about all this and wondering why the FossFactory project didn't really see much adoption. Other initiatives such as Kickstart have had some success (for example the Diaspora is an example of a software project that just released something thanks to this kind of funding) but it doesn't fit very well to how small unit-of-progress would be rewarded (i.e. small bugs in bug tracking systems as opposed to whole projects) so I guess there's still some hope in micro-payment systems for this.
And indeed there is. It turns out that I joined some months ago a new company that has an internal system to reward in this way (all is explained here -- the Love Machine), and even our CEO went away some months to develop this sole idea as a separate company. Now, the way he decided to pursue it is very interesting: develop a workflow system of little rewards that companies can adopt with their employees (or with their "contractors", because with this workflow they actually don't need to have fixed salaries... --which may be good or bad, and is subject for another discussion).
I don't know much about the success of that project actually. But what I know now is that a new service around the same idea was recently born is really having a lot of adoption, because it's actually not a product that can be deployed in a company, but just a product that is deployed by a company which hosts the service, and then anyone can send or receive micro-payments about anything so it's not a service from a company to a company but from a company to an end-user. And the real good idea behind this is that their micro-payment system makes them be the intermediary between you and the grant-receivers you want to donate to, every month. You don't ever need again to pay N subscriptions to donate to N causes/organizations you like, you just subscribe to them, and then every month (actually everyday) you decide where your money goes too.
Didn't I explain it correctly? Well, go to see the video which is more than a thousand words and more than a million images: FLATTR.
Update 18-FEB-2013: Lots of initiatives popping up now in regards to this, so just a simple update to list some of them:
Labels: CSharp, General, Ingenieria, Mono, Mozilla, Programacion, SoftwareLibre
Wednesday, April 09, 2008
Mono news FROM/FOR the Spanish side
[English version below]
DESDE: Me enorgullece comunicar que finalmente el Planeta Mono-Hispano ha resucitado! Felicitaciones a toda la gente involucrada en que esto saliera adelante.
PARA: Si estás terminando tu carrera de Ingeniería Superior en Informática en la UPM (donde yo la hice también), conozco una profesora que está buscando un alumno para hacer un PFC en el que tendrá que usar Silverlight/Moonlight, así que si estás interesado, ponte en contacto conmigo!
--
FROM: I'm glad to tell that finally the Mono-Hispano Planet has resurrected! Congratulations to all the guys involved in making this happen.
FOR: If you are finishing your engineer's degree in Computer Science at the UPM university (where I did in the past), I know a teacher that is looking for a student to do his PFC (how do you guys call this en English?) using Silverlight/Moonlight, so if you're interested, contact me!
DESDE: Me enorgullece comunicar que finalmente el Planeta Mono-Hispano ha resucitado! Felicitaciones a toda la gente involucrada en que esto saliera adelante.
PARA: Si estás terminando tu carrera de Ingeniería Superior en Informática en la UPM (donde yo la hice también), conozco una profesora que está buscando un alumno para hacer un PFC en el que tendrá que usar Silverlight/Moonlight, así que si estás interesado, ponte en contacto conmigo!
--
[English version]
FROM: I'm glad to tell that finally the Mono-Hispano Planet has resurrected! Congratulations to all the guys involved in making this happen.
FOR: If you are finishing your engineer's degree in Computer Science at the UPM university (where I did in the past), I know a teacher that is looking for a student to do his PFC (how do you guys call this en English?) using Silverlight/Moonlight, so if you're interested, contact me!
Labels: CSharp, General, Ingenieria, Mono, Programacion, SoftwareLibre, WebDev
Saturday, December 23, 2006
Esos pelacables telemáticos
La expresión "pelacables" la aprendí en mi facultad para designar despectivamente a nuestros compañeros ingenieros de telecomunicación. Desde entonces uso el término a menudo para referirme a ellos, pero siempre desde el sentido del humor, claro está.
Pero aunque me suelen caer bien, el colectivo de los colegios oficiales de ingenieros de telecomunicación parece que se están llevando el gato al agua en sus maniobras de robo de competencias en cuanto a atribuciones oficiales a nivel estatal se refiere.
Reproduzco un comentario de la página IngenierosDePrimera.com:
Estimados colegas:
Soy un Ingenierio Técnico en Informática de Sistemas español. Eso en mi país quiere decir bastante poco. Tanto, que tengo que estar en otro donde me pagan decentemente, no sientiéndome como un inmundo paria, intentando aprender el idioma para quedarme, pues, y lo repito una vez más, la Informática (y demás aspectos) en mi país es vomitiva.
Como estoy un poco harto con los últimos acontecimientos y me sobra esta tarde, voy a contaros un cuento, breve pero intenso, sobre mi país y su desarrollo, o mejor dicho, subdesarrollo tecnológico.
Todos sabemos que nuestro país es peculiar en muchos sentidos, no vamos a descubrir América ahora. Con respecto a la Ingenería Informática se ha cometido una injusticia histórica sin precedente, con dos únicos culpables y su opresión: la Ingenería de Telecomunicaciones y la tendencia española al vivir del otro sin trabajar.
¿Cómo he llegado a estas conclusiones? No es muy difícil. De forma extraña a todos los países de la Tierra, España no tiene una Ingenería en Electrónica de primer ciclo. EEE la llaman por ahí. El que ha salido un poco de su pueblo sabe de qué estoy hablando. En cambio es un segundo ciclo y sólo se puede acceder por medio de (aquí está el truco): ¡la Ingeniería de Telecomunicaciones!. Haciendo un análisis rigurosos se puede comprobar que la Ing. de Telecomunicaciones no deja de ser una Ingeniería en Electrónica, con otro nombre.
Una vez que el desarrollo tecnológico de finales del S.XX seguía su curso, en España la Ing. de Telecomunicación, partiendo de un error de base (y por ello, condenada como estaba en el tiempo) comenzó a adquirir competencias que no le pertenecían, para poder sobrevivir. Hoy día se hacen proyectos de redes neuronales por parte de profesores de Telecomunicaciones ... ¿qué sentido tiene todo esto? Hoy día un Ingeniero en Informática no puede firmar proyectos de Seguridad Informática. ¿Cómo puede ser esto? ¿Un médico acaso hace barcos o dicta leyes? No entiendo por qué un Ingeniero en Electrónica Camuflado (Ing. de Telec) hace mi trabajo y encima, con todo el recochineo del mundo, me coharta, coacciona y me impide a mí, que soy IeI con todas las de la ley, firmar ese tipo de proyectos.
La primera consecuencia de esa incipiente extinción de los IEC's es la Ingeniería Técnica de Telec. en Telemática y su caída inminente. Como todos sabéis, Bolonia le ha leído la cartilla a esta disciplina absurda donde las haya, provocando su desaparición del catálogo. Ahora están nerviosos. Han hecho una plataforma paripé de "SI A LA TELEMÁTICA". Por lo visto no tiene mucho éxito, pues debería llamarse: "SÍ A VIVIR DEL CUENTO". Serán los primeros en desaparecer. Porque hay que preguntarse, ¿qué es la TELEMATICA? Te dirán: "Está claro, un teleco que puede trabajar de informático". Pero ahora sabemos que el concepto teleco no existe, así que sustituyamos por "Ingeniero Electrónico orientado a las Comunicaciones que puede trabajar de informático". Pero, ¿qué es informático?.... No, esa persona está queriendo decir: "Ingeniero Electrónico orientado a las Comunicaciones que puede realizar trabajos de Ingeniería Informática". Eso es hablar con propiedad y decir la verdad. Y además, hacer ver a la gente lo ridícula que era la primera frase. ¿Eres Ingeniero Informático, IEC? No. No me gusta ir diciendo por ahí que soy médico, si no lo soy.
Como resultado de todo este crisol de incongruencias universitarias, se ha cometido una gran injusticia en la aplicación de las directivas en las carreras nuevas. Volvemos a quedar aparte. Somos el único caso en toda Europa. Por eso debemos pararlo antes de que lo aprueben. Es la última oportunidad para darles en los morros a esos corruptos que nos cierran todas las puertas, que no nos dan dignidad y quieren vivir a nuestra costa. Si aprueban la nueva ley, seréis unos parias de por vida. Nunca tendréis derechos reales. Aquí tenéis más información:
http://www.ingenierosdeprimera.com/node/132
¿Pero qué demonios se han creído? ¿Quién se cree esta gente? Si mañana queremos paramos el país. Ni pilotos, ni gaitas en vinagre. Si yo no hay trabajo, no hay datos. Si no hay datos, no hay comercio, no hay sanidad, no hay vuelos ... no hay nada. Sólo el caos. Ahí está lo que queríais oír: tenéis el poder. Usadlo sin complejos.
¿Pero el poder para qué? Para obtener el Colegio Nacional de Ingenieros en Informática y ganar las atribuciones. Sólo con dos estos dos hitos se habrá acabado la pesadilla. Ya no tendrás que hacer más horas extra. No tendrá que trabajar por míseros 800 euros al mes. ¿Os imagináis 200.000 personas afiliadas en la misma causa, la misma asociación? Ahora me dirás que tú no crees en las asociaciones, que si tal, que si cuál ... Bienvenido al mundo real. La vida es dura y como no defiendas lo tuyo no te van a dar nada. La época romántica de la Informática ya terminó. Así que afeitate la perilla, lávate un poco y apoya la causa. Que es TU causa, a ver si te enteras ya. ¿O quieres ser un esclavo toda tu vida?
Una buena piedra angular puede ser ésta: www.ingenierosdeprimera.com. Ni hago la página ni la apoyo. Pero estoy harto como mucha gente y todo esto debe cambiar. ¿Qué importa desde dónde? Y recordar, la unión hace la fuerza.
Que yo sea el último emigrado de la diáspora de IeI de España.
F.I.L. Viena 22/12/2006 --- 2007 Primer año del respeto a la Ingeniería Informática en España
La verdad es que estas declaraciones dan bastante respeto. No me opongo a que un ingeniero de telecomunicación se gane el pan programando o auditando la seguridad de un sistema informático. A lo que me opongo es a que se de por hecho oficialmente que este tipo de tareas no estén atribuidas a un ingeniero informático.
Parece que el comentario se ha convertido en una entrada de la web de Ingenieros de Primera. Una web que trata de centralizar los esfuerzos en pro de los intereses del conjunto de todo tipo de colectivos de profesionales informáticos en España. El punto más importante en la actualidad es la lucha contra el plan de Bolonia cuya implementación española (por parte del Ministerio de Educación y Ciencia) pretende dejar de calificar a los ingenieros en informática como ingenieros y dejarles sin atribuciones oficiales (es decir, dejarnos como ingenieros de segunda).
Actualización 06-ENE-2007: He decidido cambiar el título de la entrada (cambiando "informáticos" por "telemáticos") a cuento de una maravillosa web que he encontrado.
Actualización 14-ABR-2007: Es acojonante que se prolongue más esta situación: para acceder al Cuerpo Superior de Sistemas y Tecnologías de la Información del Estado no se requiere tener ninguna titulación informática, tan sólo ser licenciado, cuando por el contrario para los Cuerpos Superiores o Técnicos análogos de otras ramas de la Ingeniería como Industriales, Agrónomos, Arquitectos, sólo los poseedores de los correspondientes títulos pueden presentarse.
Pero aunque me suelen caer bien, el colectivo de los colegios oficiales de ingenieros de telecomunicación parece que se están llevando el gato al agua en sus maniobras de robo de competencias en cuanto a atribuciones oficiales a nivel estatal se refiere.
Reproduzco un comentario de la página IngenierosDePrimera.com:
Estimados colegas:
Soy un Ingenierio Técnico en Informática de Sistemas español. Eso en mi país quiere decir bastante poco. Tanto, que tengo que estar en otro donde me pagan decentemente, no sientiéndome como un inmundo paria, intentando aprender el idioma para quedarme, pues, y lo repito una vez más, la Informática (y demás aspectos) en mi país es vomitiva.
Como estoy un poco harto con los últimos acontecimientos y me sobra esta tarde, voy a contaros un cuento, breve pero intenso, sobre mi país y su desarrollo, o mejor dicho, subdesarrollo tecnológico.
Todos sabemos que nuestro país es peculiar en muchos sentidos, no vamos a descubrir América ahora. Con respecto a la Ingenería Informática se ha cometido una injusticia histórica sin precedente, con dos únicos culpables y su opresión: la Ingenería de Telecomunicaciones y la tendencia española al vivir del otro sin trabajar.
¿Cómo he llegado a estas conclusiones? No es muy difícil. De forma extraña a todos los países de la Tierra, España no tiene una Ingenería en Electrónica de primer ciclo. EEE la llaman por ahí. El que ha salido un poco de su pueblo sabe de qué estoy hablando. En cambio es un segundo ciclo y sólo se puede acceder por medio de (aquí está el truco): ¡la Ingeniería de Telecomunicaciones!. Haciendo un análisis rigurosos se puede comprobar que la Ing. de Telecomunicaciones no deja de ser una Ingeniería en Electrónica, con otro nombre.
Una vez que el desarrollo tecnológico de finales del S.XX seguía su curso, en España la Ing. de Telecomunicación, partiendo de un error de base (y por ello, condenada como estaba en el tiempo) comenzó a adquirir competencias que no le pertenecían, para poder sobrevivir. Hoy día se hacen proyectos de redes neuronales por parte de profesores de Telecomunicaciones ... ¿qué sentido tiene todo esto? Hoy día un Ingeniero en Informática no puede firmar proyectos de Seguridad Informática. ¿Cómo puede ser esto? ¿Un médico acaso hace barcos o dicta leyes? No entiendo por qué un Ingeniero en Electrónica Camuflado (Ing. de Telec) hace mi trabajo y encima, con todo el recochineo del mundo, me coharta, coacciona y me impide a mí, que soy IeI con todas las de la ley, firmar ese tipo de proyectos.
La primera consecuencia de esa incipiente extinción de los IEC's es la Ingeniería Técnica de Telec. en Telemática y su caída inminente. Como todos sabéis, Bolonia le ha leído la cartilla a esta disciplina absurda donde las haya, provocando su desaparición del catálogo. Ahora están nerviosos. Han hecho una plataforma paripé de "SI A LA TELEMÁTICA". Por lo visto no tiene mucho éxito, pues debería llamarse: "SÍ A VIVIR DEL CUENTO". Serán los primeros en desaparecer. Porque hay que preguntarse, ¿qué es la TELEMATICA? Te dirán: "Está claro, un teleco que puede trabajar de informático". Pero ahora sabemos que el concepto teleco no existe, así que sustituyamos por "Ingeniero Electrónico orientado a las Comunicaciones que puede trabajar de informático". Pero, ¿qué es informático?.... No, esa persona está queriendo decir: "Ingeniero Electrónico orientado a las Comunicaciones que puede realizar trabajos de Ingeniería Informática". Eso es hablar con propiedad y decir la verdad. Y además, hacer ver a la gente lo ridícula que era la primera frase. ¿Eres Ingeniero Informático, IEC? No. No me gusta ir diciendo por ahí que soy médico, si no lo soy.
Como resultado de todo este crisol de incongruencias universitarias, se ha cometido una gran injusticia en la aplicación de las directivas en las carreras nuevas. Volvemos a quedar aparte. Somos el único caso en toda Europa. Por eso debemos pararlo antes de que lo aprueben. Es la última oportunidad para darles en los morros a esos corruptos que nos cierran todas las puertas, que no nos dan dignidad y quieren vivir a nuestra costa. Si aprueban la nueva ley, seréis unos parias de por vida. Nunca tendréis derechos reales. Aquí tenéis más información:
http://www.ingenierosdeprimera.com/node/132
¿Pero qué demonios se han creído? ¿Quién se cree esta gente? Si mañana queremos paramos el país. Ni pilotos, ni gaitas en vinagre. Si yo no hay trabajo, no hay datos. Si no hay datos, no hay comercio, no hay sanidad, no hay vuelos ... no hay nada. Sólo el caos. Ahí está lo que queríais oír: tenéis el poder. Usadlo sin complejos.
¿Pero el poder para qué? Para obtener el Colegio Nacional de Ingenieros en Informática y ganar las atribuciones. Sólo con dos estos dos hitos se habrá acabado la pesadilla. Ya no tendrás que hacer más horas extra. No tendrá que trabajar por míseros 800 euros al mes. ¿Os imagináis 200.000 personas afiliadas en la misma causa, la misma asociación? Ahora me dirás que tú no crees en las asociaciones, que si tal, que si cuál ... Bienvenido al mundo real. La vida es dura y como no defiendas lo tuyo no te van a dar nada. La época romántica de la Informática ya terminó. Así que afeitate la perilla, lávate un poco y apoya la causa. Que es TU causa, a ver si te enteras ya. ¿O quieres ser un esclavo toda tu vida?
Una buena piedra angular puede ser ésta: www.ingenierosdeprimera.com. Ni hago la página ni la apoyo. Pero estoy harto como mucha gente y todo esto debe cambiar. ¿Qué importa desde dónde? Y recordar, la unión hace la fuerza.
Que yo sea el último emigrado de la diáspora de IeI de España.
F.I.L. Viena 22/12/2006 --- 2007 Primer año del respeto a la Ingeniería Informática en España
La verdad es que estas declaraciones dan bastante respeto. No me opongo a que un ingeniero de telecomunicación se gane el pan programando o auditando la seguridad de un sistema informático. A lo que me opongo es a que se de por hecho oficialmente que este tipo de tareas no estén atribuidas a un ingeniero informático.
Parece que el comentario se ha convertido en una entrada de la web de Ingenieros de Primera. Una web que trata de centralizar los esfuerzos en pro de los intereses del conjunto de todo tipo de colectivos de profesionales informáticos en España. El punto más importante en la actualidad es la lucha contra el plan de Bolonia cuya implementación española (por parte del Ministerio de Educación y Ciencia) pretende dejar de calificar a los ingenieros en informática como ingenieros y dejarles sin atribuciones oficiales (es decir, dejarnos como ingenieros de segunda).
Actualización 06-ENE-2007: He decidido cambiar el título de la entrada (cambiando "informáticos" por "telemáticos") a cuento de una maravillosa web que he encontrado.
Actualización 14-ABR-2007: Es acojonante que se prolongue más esta situación: para acceder al Cuerpo Superior de Sistemas y Tecnologías de la Información del Estado no se requiere tener ninguna titulación informática, tan sólo ser licenciado, cuando por el contrario para los Cuerpos Superiores o Técnicos análogos de otras ramas de la Ingeniería como Industriales, Agrónomos, Arquitectos, sólo los poseedores de los correspondientes títulos pueden presentarse.
Labels: General, Ingenieria, Politica
Monday, December 19, 2005
El arquitecto de software
Al hilo de una conversación en BarraPunto sobre "Telecos e informáticos, los más solicitados", se discutió mucho sobre los colegios oficiales de ingenieros en informática, como siempre.
Uno de los comentarios que más puntos recibió consideraba comprensible que los ingenieros de nuestra especialidad abogasen por la implantación de colegios oficiales, siempre y cuando los ingenieros dejaran de "codificar" y se dedicasen a las tareas para las que realmente fueron concebidos y preparados.
Considero que este señor tiene parte de razón, aunque la línea que separaría un tipo de tareas de otras estaría bastante difuminada dado que la diferencia parece algo subjetiva. Sobre todo si tenemos en cuenta las típicas tareas que podría desempeñar un Arquitecto de software (y recordando que la aserción Architects Don't Code es un anti-patrón, es decir, algo totalmente incorrecto y a evitar). Algunas de estas tareas las mencioné en un comentario que puse de respuesta en BarraPunto pero las vuelvo a mencionar aquí:
Una de ellas, la número 3, la considero la más importante de todas y, paradójicamente, la que en general en la industria informática se tiene menos en cuenta. Hay que pensar que esta tarea no sólo sirve para cuidar la calidad de un desarrollo, también para evitar complejidades innecesarias, reutilizaciones de código no empleadas, y que ciertos personajillos se aseguren un trabajo de por vida a base de escribir código inmantenible.
Actualización 19-AGO-2007: Leyendo una entrada del blog de Ayende se me ha ocurrido otro elemento importante que hace un arquitecto de software: revisión arquitectural del sistema (pues la revisión no arquitectural de cada uno de los cambios de cada programador es una tarea demasiado larga como para que sólo la lleve a cabo una persona) para que el sistema no se convierta en The Blob (otro antipatrón). Ah, y Ayende también está de acuerdo en que Architects don't code es un antipatrón.
Actualización 27-SEP-2007: Veo que me siento totalmente identificado con las palabras de una acojonante entrada de Ted Neward, la cual voy a citar (énfasis añadido):
How could their idea of an architect be so far removed from someone like myself? I can't answer this one solidly, but I can say that the definition of an architect seems to be vague and indiscriminate a term, only exceeded in opacity by the term "software" itself. For some companies I've worked for, the "architect" was as you describe yourself, someone whose hands were dirty with code, acting as technical lead, developer, sometimes-project-manager, and always focused on customer/business value as well as technical details. At other places, the architect (or "architect team") was a group of developers who had to be promoted (usually due to longevity) with no clear promotion path available to them other than management. This "architect team" then lays down "corporate standards", usually based on "industry standards", with little to no feedback as to the applicability of their standards to the problems faced by the developers underneath them. A friend of mine on the NFJS tour, Brian Sletten, tells a story of how he consulted on a project, implementing the (powerful) 1060 Netkernel toolkit at the core of the system, to resounding success. Then, on deployment, the "architecture team" took a look, pronounced the system to be incompatible with their "official standards", and forced new development of a working product. In other words, the fact that it worked (and could easily be turned to interoperate with their SOAP-based standard, of which there were zero existing services) was in no way going to stand as an impediment to their enforcement of the corporate standard.
Is architecture supposed to be facilitative or restrictive? Ah, this is a harder one to answer. In essence, both. Now, before the crowd starts getting out their torches and pitchforks to have a good old-fashioned lynching, hear me out.
Architecture is intended to be facilitative, of course, in that a good architecture should enable developers to build applications quickly and easily, without having to spend significant amounts of time re-inventing similar infrastructure across multiple projects. A good architecture will also facilitate interoperability across applications, ensure a good code quality, ensure good maintainability, provide for future extensibility, and so on. All of this, I would argue, falls under the heading of "facilitation".
But an architecture is also intended to be restrictive, in that it should channel software developers in a direction that leads to all of these successes, and away from potential decisions that would lead to prolems later. In other words, as Microsoft's CLR architect Rico Mariani put it, a good architecture should enable developers to "fall into the pit of success", where if you just (to quote the proverbial surfer) "go with the flow", you make decisions that lead to all of those good qualities we just discussed.
This is asking a lot of an architecture, granted. But that's the ideal.
What relevance do architects have today? Well, this is a dangerous question, in that you're asking it of one who considers himself an architect and technologist, so take this with the usual grain of salt. Are we just overpaid out-of-touch developers? God, I hope not. Fowler talks about architecture being irrelevant in an agile project, but I disagree with that notion pretty fundamentally: an architect is the captain of the ship, making the decisions that cross multiple areas of concern (navigation, engineering, and so on), taking final responsibility for the overall health of the ship and its crew (project and its members), able to step into any station to perform those duties as the need arises (write code for any part of the project should they lose a member). He has to be familiar with the problem domain, the technology involved, and keep an eye out on new technologies that might make the project easier or answer new customers' feature requests.
And if anybody stands up at this point and says, "Hey, wait a minute, that's a pretty tall order for anybody to fill!", then you start to get an idea of why architects do, frequently, get paid more than developers do. Having to know the business, the technology at a high and low level of detail, keeping your hands in the code, and watching the horizon for new developments in industry, is a pretty good way to burn out any free time you might have thought you'd have.
Granted, all of these answers notwithstanding, there's a large number of "architects" out there whose principal goal is to simply remain employed. To do that, they cite "best practices" established by "industry experts" as a cover for making decisions of their own, because nobody ever gets fired for choosing what industry "best practices" dictate. That's partly why I hate that term: it's a cop-out. It's basically relying on articles on popular websites and magazines to do your thinking for you. Inevitably, when somebody at a conference says the word, "Best Practice", listeners' minds turn off, their pens turn on, and they dutifully enscribe this bit of knowledge into their projects at home, without considering the applicability to their project or corporate culture. Nothing, not a single technology, not a single development methodology, not even a single tool, is always the right answer.
Actualización 09-FEB-2008: Voy a citar dos fuentes más de información que expresan muy bien lo que es un arquitecto de software o la calidad del software que éste debe perseguir.
La primera es un párrafo del mítico libro The Mythical Man-Month, válgame la redundancia, citado en esta entrada de Scott Rosenberg:
The goal of "conceptual integrity" or unity of design: The best programs and software systems exhibit a sense of consistency and elegance, as if they are shaped by a single creative mind, even when they are in fact the product of many. The fiendish problem is less how to create that sense in the first place than in how to preserve it against all the other pressures that come to bear throughout the process of writing software.
Por último, dos párrafos sueltos de una entrada de Ayende Rahien titulada "Don't meake me THINK!", que habla sobre arquitectura y usabilidad:
A while ago I was asked what I think was a good quality for an architect. My reply was that he should set things up in such a way where the developers are bored.
That may sound... harsh to some, but I believe that we have enough complexity in our applications as it is. A success story is reducing the complexity to such a level that we focus on the business value, rather on the technical difficulties.
[...]
This means that we can spend all the time actually producing business value. It also means that I have a lot of junior people on my team that can immediately make use of very advance concepts and produce good, solid software.
Actualizacion 17-MAY-2008: Don't Let Architecture Astronauts Scare You es una interesante entrada de Joel Spolsky que desmitifica al perfil de arquitecto-soluciona-todo. No es que se meta con los arquitectos de software (aunque alguna frase sí me ha dolido, como Remember that the architecture people are solving problems that they think they can solve, not problems which are useful to solve), sino con el aire marketiniano que se le da algunas veces a cosas relacionadas con la arquitectura, pero que al final acaban resolviendo algo interno (no visible al usuario).
Y me ha dolido porque pienso que la arquitectura sí es algo util de resolver/perfeccionar, dependiendo del punto de vista claro. Y aquí voy a usar el símil que el mismo Joel ha utilizado: ?le interesa al cliente de un supermercado saber que los productos se llevan en camión desde el almacen? No. Pero, ?es por eso menos importante la eficiencia de los procesos internos para que el cliente pueda disfrutar de su producto finalmente? No.
Actualizacion 02-NOV-2008: Es triste como parece que España sigue igual en cuanto a la mentalidad de muchos informáticos. Cuando alguien te diga cosas como "¿Programando a los 50? No, por favor" o "A ver cuando me ascienden para dejar de programar", es que no es un auténtico ingeniero de software con vocación, y me apuesto a que no sabrá ni siquiera lo que es un arquitecto de software (un puesto de lo más relevante, y que precisamente suele ser la aspiración de los que quieren progresar en su carrera pero sin dejar de programar, puesto que es su pasión).
Uno de los comentarios que más puntos recibió consideraba comprensible que los ingenieros de nuestra especialidad abogasen por la implantación de colegios oficiales, siempre y cuando los ingenieros dejaran de "codificar" y se dedicasen a las tareas para las que realmente fueron concebidos y preparados.
Considero que este señor tiene parte de razón, aunque la línea que separaría un tipo de tareas de otras estaría bastante difuminada dado que la diferencia parece algo subjetiva. Sobre todo si tenemos en cuenta las típicas tareas que podría desempeñar un Arquitecto de software (y recordando que la aserción Architects Don't Code es un anti-patrón, es decir, algo totalmente incorrecto y a evitar). Algunas de estas tareas las mencioné en un comentario que puse de respuesta en BarraPunto pero las vuelvo a mencionar aquí:
- Estudio de nuevas herramientas, librerías, componentes.
- Elaboración de guías de estilo de codificación.
- Revisiones de las implementaciones/parches de los programadores.
- Implementaciones de partes globales de un sistema, que posteriormente serán utilizadas por los programadores (p.ej: creación y mantenimiento de una herramienta base, un "framework" del negocio).
- Formación a programadores.
- Generación de pruebas unitarias y de regresión, y planes/herramientas para la automatización de estas pruebas.
Una de ellas, la número 3, la considero la más importante de todas y, paradójicamente, la que en general en la industria informática se tiene menos en cuenta. Hay que pensar que esta tarea no sólo sirve para cuidar la calidad de un desarrollo, también para evitar complejidades innecesarias, reutilizaciones de código no empleadas, y que ciertos personajillos se aseguren un trabajo de por vida a base de escribir código inmantenible.
Actualización 19-AGO-2007: Leyendo una entrada del blog de Ayende se me ha ocurrido otro elemento importante que hace un arquitecto de software: revisión arquitectural del sistema (pues la revisión no arquitectural de cada uno de los cambios de cada programador es una tarea demasiado larga como para que sólo la lleve a cabo una persona) para que el sistema no se convierta en The Blob (otro antipatrón). Ah, y Ayende también está de acuerdo en que Architects don't code es un antipatrón.
Actualización 27-SEP-2007: Veo que me siento totalmente identificado con las palabras de una acojonante entrada de Ted Neward, la cual voy a citar (énfasis añadido):
How could their idea of an architect be so far removed from someone like myself? I can't answer this one solidly, but I can say that the definition of an architect seems to be vague and indiscriminate a term, only exceeded in opacity by the term "software" itself. For some companies I've worked for, the "architect" was as you describe yourself, someone whose hands were dirty with code, acting as technical lead, developer, sometimes-project-manager, and always focused on customer/business value as well as technical details. At other places, the architect (or "architect team") was a group of developers who had to be promoted (usually due to longevity) with no clear promotion path available to them other than management. This "architect team" then lays down "corporate standards", usually based on "industry standards", with little to no feedback as to the applicability of their standards to the problems faced by the developers underneath them. A friend of mine on the NFJS tour, Brian Sletten, tells a story of how he consulted on a project, implementing the (powerful) 1060 Netkernel toolkit at the core of the system, to resounding success. Then, on deployment, the "architecture team" took a look, pronounced the system to be incompatible with their "official standards", and forced new development of a working product. In other words, the fact that it worked (and could easily be turned to interoperate with their SOAP-based standard, of which there were zero existing services) was in no way going to stand as an impediment to their enforcement of the corporate standard.
Is architecture supposed to be facilitative or restrictive? Ah, this is a harder one to answer. In essence, both. Now, before the crowd starts getting out their torches and pitchforks to have a good old-fashioned lynching, hear me out.
Architecture is intended to be facilitative, of course, in that a good architecture should enable developers to build applications quickly and easily, without having to spend significant amounts of time re-inventing similar infrastructure across multiple projects. A good architecture will also facilitate interoperability across applications, ensure a good code quality, ensure good maintainability, provide for future extensibility, and so on. All of this, I would argue, falls under the heading of "facilitation".
But an architecture is also intended to be restrictive, in that it should channel software developers in a direction that leads to all of these successes, and away from potential decisions that would lead to prolems later. In other words, as Microsoft's CLR architect Rico Mariani put it, a good architecture should enable developers to "fall into the pit of success", where if you just (to quote the proverbial surfer) "go with the flow", you make decisions that lead to all of those good qualities we just discussed.
This is asking a lot of an architecture, granted. But that's the ideal.
What relevance do architects have today? Well, this is a dangerous question, in that you're asking it of one who considers himself an architect and technologist, so take this with the usual grain of salt. Are we just overpaid out-of-touch developers? God, I hope not. Fowler talks about architecture being irrelevant in an agile project, but I disagree with that notion pretty fundamentally: an architect is the captain of the ship, making the decisions that cross multiple areas of concern (navigation, engineering, and so on), taking final responsibility for the overall health of the ship and its crew (project and its members), able to step into any station to perform those duties as the need arises (write code for any part of the project should they lose a member). He has to be familiar with the problem domain, the technology involved, and keep an eye out on new technologies that might make the project easier or answer new customers' feature requests.
And if anybody stands up at this point and says, "Hey, wait a minute, that's a pretty tall order for anybody to fill!", then you start to get an idea of why architects do, frequently, get paid more than developers do. Having to know the business, the technology at a high and low level of detail, keeping your hands in the code, and watching the horizon for new developments in industry, is a pretty good way to burn out any free time you might have thought you'd have.
Granted, all of these answers notwithstanding, there's a large number of "architects" out there whose principal goal is to simply remain employed. To do that, they cite "best practices" established by "industry experts" as a cover for making decisions of their own, because nobody ever gets fired for choosing what industry "best practices" dictate. That's partly why I hate that term: it's a cop-out. It's basically relying on articles on popular websites and magazines to do your thinking for you. Inevitably, when somebody at a conference says the word, "Best Practice", listeners' minds turn off, their pens turn on, and they dutifully enscribe this bit of knowledge into their projects at home, without considering the applicability to their project or corporate culture. Nothing, not a single technology, not a single development methodology, not even a single tool, is always the right answer.
Actualización 09-FEB-2008: Voy a citar dos fuentes más de información que expresan muy bien lo que es un arquitecto de software o la calidad del software que éste debe perseguir.
La primera es un párrafo del mítico libro The Mythical Man-Month, válgame la redundancia, citado en esta entrada de Scott Rosenberg:
The goal of "conceptual integrity" or unity of design: The best programs and software systems exhibit a sense of consistency and elegance, as if they are shaped by a single creative mind, even when they are in fact the product of many. The fiendish problem is less how to create that sense in the first place than in how to preserve it against all the other pressures that come to bear throughout the process of writing software.
Por último, dos párrafos sueltos de una entrada de Ayende Rahien titulada "Don't meake me THINK!", que habla sobre arquitectura y usabilidad:
A while ago I was asked what I think was a good quality for an architect. My reply was that he should set things up in such a way where the developers are bored.
That may sound... harsh to some, but I believe that we have enough complexity in our applications as it is. A success story is reducing the complexity to such a level that we focus on the business value, rather on the technical difficulties.
[...]
This means that we can spend all the time actually producing business value. It also means that I have a lot of junior people on my team that can immediately make use of very advance concepts and produce good, solid software.
Actualizacion 17-MAY-2008: Don't Let Architecture Astronauts Scare You es una interesante entrada de Joel Spolsky que desmitifica al perfil de arquitecto-soluciona-todo. No es que se meta con los arquitectos de software (aunque alguna frase sí me ha dolido, como Remember that the architecture people are solving problems that they think they can solve, not problems which are useful to solve), sino con el aire marketiniano que se le da algunas veces a cosas relacionadas con la arquitectura, pero que al final acaban resolviendo algo interno (no visible al usuario).
Y me ha dolido porque pienso que la arquitectura sí es algo util de resolver/perfeccionar, dependiendo del punto de vista claro. Y aquí voy a usar el símil que el mismo Joel ha utilizado: ?le interesa al cliente de un supermercado saber que los productos se llevan en camión desde el almacen? No. Pero, ?es por eso menos importante la eficiencia de los procesos internos para que el cliente pueda disfrutar de su producto finalmente? No.
Actualizacion 02-NOV-2008: Es triste como parece que España sigue igual en cuanto a la mentalidad de muchos informáticos. Cuando alguien te diga cosas como "¿Programando a los 50? No, por favor" o "A ver cuando me ascienden para dejar de programar", es que no es un auténtico ingeniero de software con vocación, y me apuesto a que no sabrá ni siquiera lo que es un arquitecto de software (un puesto de lo más relevante, y que precisamente suele ser la aspiración de los que quieren progresar en su carrera pero sin dejar de programar, puesto que es su pasión).
Labels: General, Ingenieria, Programacion
Sunday, November 27, 2005
eXtreme Programming: La chispa adecuada
Estos días he estado desempolvando una carpeta de mis marcadores titulada "Lecturas pendientes". Son enlaces que en su día me parecieron interesantes pero demasiado largos de leer en ese momento (una idea similar a lo que son los FIXMEs en el código).
Uno de los enlaces a los que he llegado ha sido extremadamente interesante. Tanto, que los enlaces dentro de éste me han hecho abrir pestañas y más pestañas de mi navegador, hasta darme cuenta de que tendría que crear una carpeta nueva de "Lecturas pendientes". Sin comerlo ni beberlo, había dado con un Wiki que al parecer se mantiene por una empresa, o bien los empleados de una empresa, que fue la precursora de la metodología de programación "Extreme Programming"; o por lo menos eso es lo que se deduce de todas las páginas que llevo leídas.
Las entradas del Wiki son de lo más variado. En principio parece una recopilación de "reglas" y "conceptos" que han intentado ser aunados a partir de muchas experiencias y vivencias de estos ingenieros a lo largo de sus proyectos de software. Leyendo muchos de ellos te sientes identificado con cosas que te han pasado y también aprendes mucho sobre las mejores formas de actuar ante estas, o sobre nuevas situaciones que pueden ocurrirte en el futuro. Es como una recopilación de una serie de "patrones", pero no de programación, sino que se tratarían más bien de unos "patrones del informático". Son patrones con un sentido más social, algo más parecido a la ingeniería del software de alto nivel. Dos ejemplos para entender lo que digo pueden ser "EgolessProgramming" y "OnceAndOnlyOnce". El primero describe una técnica para olvidarnos de nuestro ego a la hora de programar, de manera que facilitamos la labor del programador venidero. La segunda describe el porqué hemos siempre de evitar las redundancias en el código, debiendo refactorizarlas siempre que podamos.
Y ahora nos podríamos preguntar, ¿por qué el título de esta entrada lleva el título de una canción de Héroes del Silencio? Pues bien, porque en mi lectura constante y casi maniática de este wiki me he ido encontrando, poco a poco, con cosas que incluso tienden a salirse un poco de esta línea de "patrones de informático". Por ejemplo, he leído entradas como Geta Life o Its Justa Job, que casi están más relacionadas con la psicología laboral del informático.
Pero la que más me ha sorprendido ha sido Way To Win. Es una entrada que describe el concepto, EMO, totalmente verdadero, de que, sea lo que sea aquello que te está ocurriendo, siempre podría existir un camino, una manera de hacer las cosas, que hiciera que todo se arreglara, que todo fuera bien. Lo que ocurre realmente es que sólo necesitas la chispa adecuada para que ello suceda. Es algo que también describe muy bien la letra de la citada canción.
Y para terminar la entrada en la bitácora, dejo aquí los enlaces a las entradas del Wiki que me han parecido interesantes (pondré un asterisco en las más populares):
Hay que advertir también que no todos los elementos de esta lista son patrones, sino también anti-patrones, como por ejemplo "Architects Don't Code".
Y un último inciso sobre dos de ellas: "Green Bar Addiction" me recuerda mucho al tinderbox de Mozilla, jeje; y "Peter Principle" parece corresponderse con el Principio de Máxima Incompetencia del que he oído hablar tanto y que EMO ocurre mucho en España.
Uno de los enlaces a los que he llegado ha sido extremadamente interesante. Tanto, que los enlaces dentro de éste me han hecho abrir pestañas y más pestañas de mi navegador, hasta darme cuenta de que tendría que crear una carpeta nueva de "Lecturas pendientes". Sin comerlo ni beberlo, había dado con un Wiki que al parecer se mantiene por una empresa, o bien los empleados de una empresa, que fue la precursora de la metodología de programación "Extreme Programming"; o por lo menos eso es lo que se deduce de todas las páginas que llevo leídas.
Las entradas del Wiki son de lo más variado. En principio parece una recopilación de "reglas" y "conceptos" que han intentado ser aunados a partir de muchas experiencias y vivencias de estos ingenieros a lo largo de sus proyectos de software. Leyendo muchos de ellos te sientes identificado con cosas que te han pasado y también aprendes mucho sobre las mejores formas de actuar ante estas, o sobre nuevas situaciones que pueden ocurrirte en el futuro. Es como una recopilación de una serie de "patrones", pero no de programación, sino que se tratarían más bien de unos "patrones del informático". Son patrones con un sentido más social, algo más parecido a la ingeniería del software de alto nivel. Dos ejemplos para entender lo que digo pueden ser "EgolessProgramming" y "OnceAndOnlyOnce". El primero describe una técnica para olvidarnos de nuestro ego a la hora de programar, de manera que facilitamos la labor del programador venidero. La segunda describe el porqué hemos siempre de evitar las redundancias en el código, debiendo refactorizarlas siempre que podamos.
Y ahora nos podríamos preguntar, ¿por qué el título de esta entrada lleva el título de una canción de Héroes del Silencio? Pues bien, porque en mi lectura constante y casi maniática de este wiki me he ido encontrando, poco a poco, con cosas que incluso tienden a salirse un poco de esta línea de "patrones de informático". Por ejemplo, he leído entradas como Geta Life o Its Justa Job, que casi están más relacionadas con la psicología laboral del informático.
Pero la que más me ha sorprendido ha sido Way To Win. Es una entrada que describe el concepto, EMO, totalmente verdadero, de que, sea lo que sea aquello que te está ocurriendo, siempre podría existir un camino, una manera de hacer las cosas, que hiciera que todo se arreglara, que todo fuera bien. Lo que ocurre realmente es que sólo necesitas la chispa adecuada para que ello suceda. Es algo que también describe muy bien la letra de la citada canción.
Y para terminar la entrada en la bitácora, dejo aquí los enlaces a las entradas del Wiki que me han parecido interesantes (pondré un asterisco en las más populares):
- Alternative Jobs For Programmers
- Annoyances.org - The Night Before Startup
- Architects Dont Code
- Architects Play Golf
- Ask The Computer
- Big Design Up Front *
- Blame Yourself First
- Burn Out
- Category Testing
- Chief Architect
- Code Harvesting
- Code Ownership *
- Companies Doing Xp *
- Copy And Paste Programming *
- Continuous Review *
- Creeping Featuritis *
- Daves Real Example Where Thinking Ahead Would Have Helped
- Death March
- Developer Turned Manager
- Dialogue While Pair Programming
- Different Version From Scratch *
- Dont Call It Extreme
- Dont Repeat Yourself *
- Do It Right The First Time *
- Do The Simplest Thing That Could Possibly Work *
- Egoless Programming *
- Fear Of Adding Classes
- Full Time Open Source Developer
- Geta Life *
- Gold Plating
- Green Bar Addiction
- Heroic Programming
- Its Justa Job
- Just An Architect
- Just An Engineer
- Just An Idiot
- Just Leave
- Just Stop Doing It
- Justa Programmer
- Justa Software Engineer
- Keep It Simple Stupid *
- Let The Junior Drive
- Nomadic Programmer
- Non Coding Architects Suck
- Once And Only Once *
- Once And Only Once Is Not Just For Code
- Pair Mismatch
- Pair On
- Pair Programming *
- Pair Programming Is Done By Peers
- Pair Programming Is Not Training
- People Skills
- Perfect Architecture
- PeterPrinciple *
- Premature Generalization *
- Professional Engineer
- Project Manager
- Qualifying Employers
- Record Your Communication In The Code
- Recovering Programmer
- Software Architect
- Software Engineer
- Technical Lead
- Technical Writer
- Trial And Error Programming *
- Way To Win
- We Arent Gonna Need It
- We Dont Need It Yet
- What Is Refactoring *
- When Are We Gonna Need It
- When Xp Is Unpopular
- Yagni Exceptions
- You Are Gonna Need It
- You Arent Gonna Need It *
- You Might Need It
- Your Mileage May Vary *
Hay que advertir también que no todos los elementos de esta lista son patrones, sino también anti-patrones, como por ejemplo "Architects Don't Code".
Y un último inciso sobre dos de ellas: "Green Bar Addiction" me recuerda mucho al tinderbox de Mozilla, jeje; y "Peter Principle" parece corresponderse con el Principio de Máxima Incompetencia del que he oído hablar tanto y que EMO ocurre mucho en España.
Labels: General, Ingenieria, Programacion
Friday, June 10, 2005
AntiFUD: colegios oficiales para informáticos
Bueno bueno... Cada vez que sale un tema de este estilo en BarraPunto, se arma la de dioses cristo. Y cada vez que leo algunos comentarios, me dan muchísimas ganas de intervenir, y de hecho alguna vez lo he hecho. Sin embargo, me he cansado de dar ciertos visos de mi opinión sobre este tema, y he decidido recopilarla enteramente en una especie de "artículo" en el que doy mi opinión sobre cómo deberían ser los colegios informáticos, y en el que desmiento por completo los típicos tópicos sobre los colegios que suelen aparecer en BarraPunto (y que en mi opinión lo único que provocan es FUD's, que se extienden y se van contagiando...).
Aquí os lo dejo:
Sí, esto es un antiFUD. Sé que muchos de vosotros estáis super de acuerdo con los colegios, y también sé que otros muchos matarían para que no se construyera una nueva "mafia".
Bien, pues yo apelo a que utilicéis vuestro intelecto de una maldita vez. Vale ya de FUD's. Se acabaron los comentarios del tipo "¡fuera los intrusos!" o bien "¡abajo las mafias!".
Voy a intentar haceros ver, si os interesa claro, que uno se puede posicionar en un punto intermedio en cuanto a la opinión de si los colegios deberían existir o no. Es decir, EL GRIS EXISTE, vale ya de blancos y de negros, no seamos como la mayoría de los borregos españolitos que votan en binario.
Para empezar quiero defenderme de las típicas falacias:
Otras competencias adicionales, más subordinadas, que podrían tener los colegios:
Tengo que confesar que, a pesar de lo elaborado de mi tesis o propuesta, me siguen quedando dudas que me gustaría poder debatir. Por ejemplo, está claro que dentro de la esfera de casos englobados en el punto 2.(b) mencionado arriba cabría citar el ejemplo del desarrollo de los sistemas de seguridad software de una central nuclear, pero ¿y el software de un banco el cual pudiera, vista comprometida su seguridad, provocar daños económicos a sus clientes, los cuales son "terceros" puesto que son totalmente ajenos al contrato en el que se negocia el desarrollo del software de su entidad bancaria?
Actualización: La última entrada en BarraPunto sobre este tema es ¿A qué Asociación de informáticos me suscribo? y después de leerla he descubierto cosas interesantes. La primera es que sigue existiendo el blanco y el negro en barrapunto: los ingenieros que, cabreados por el intrusismo, quieren poner un coto a la profesión; y los no titulados que creen que son los únicos que saben trabajar, que los colegios son mafias y no sirven para nada. También he recopilado algunos enlaces de casos prácticos sobre este tema:
ALI: Asociacion de Doctores Licenciados e Ingenieros en Informática de España. El contraejemplo. Esperemos que esta gente no llegue nunca a nada. Sólo con ver su horripilante web se puede comprobar de lo que son capaces.
COIIPA: Colegio Oficial de Ingenieros en Informática del Principado de Asturias. Así es como deberían de ser todos los colegios. Tienen atribuidas una serie de funciones no intrusivas, admiten que no pretenden luchar contra el intrusismo sino sólo defenderse, y más cuestiones interesantes que aparecen en el documento de Preguntas Frecuentes sobre el colegio.
Actualización 20-NOV-2006: Reproduzco un comentario interesante de BarraPunto en una noticia de hace unos días:
Referente a los títulos, creo que se tiende a olvidar que sólo es un acreditativo de una institución que indica que has superado las pruebas necesarias para tenerlo. Nada más. Igual que el carné de conducir. Hay muy buenos conductores sin carné que no tienen accidentes y pasan desapercibidos sin pagar absolutamente nada y otros no tan buenos que tienen carne y tienen multas y accidentes. El problema viene de todo el rango entre un extremo y el otro. Pues lo mismo con los colegios. Hay profesionales, hay gentuza y gente entre ambos extremos. Yo creo que SÍ debería haber colegio, no para garantizar sueldos, sino simplemente para regular las competencias y las responsabilidades de una profesión que se ha convertido en un escudo para la incompetencia de las demás. Me explico, un aparejador tiene una regulación de lo que puede o no firmar, la responsabilidad de lo que tiene que hacer en una obra y un seguro para responder civilmente por los fallos que puede tener. Una grieta en una casa y un tío debe decir porqué. ¿Quién no ha ido a un banco y le han dicho alguna vez que los ordenadores no funcionan? ¿O las páginas web? ¿O el ordenador de la biblioteca? ¿O han cambiado sus datos? La gente de a pie no tiene porqué soportar eso y el señor del banco no tiene porqué dar mala imagen: TÚ debes pagar por ello si tu programa no cumplía las regulaciones pertinentes.
Y otro más, que habla sobre ese concepto llamado 'titulitis':
Cada vez que sale la titulitis a colación me pregunto si soy el único que ha tenido la suerte de trabajar con colegas recién escudillados de la superior y el típico personaje "con toda la experiencia que da el trabajo" y apreciar la diferencia.
Sí, la experiencia cuenta, pero el título no detrae. En todo caso aporta. Y en la mayoría de los casos se nota. Se nota en la amplitud de miras, en los conocimientos generalistas de muchas ramas de la informática; se nota en la calidad del código, en la claridad y en los principios de ingeniería de software que un programador novel ya imprime en sus primeras tareas.
Tal vez sea que mi universidad enseña decentemente la carrera, o es que en barrapunto el tener el título es un estigma, pero cada vez que alguien defiende la experiencia y acusa de titulitis yo pienso "dentro de 3 años el ingeniero tendrá ambas cosas" y quieras que no, 5 años de informática bien enseñada dejan poso para toda la vida. La universidad no es aprender java y las tecnologías de moda, es mucho más que eso (o más bien otra cosa completamente diferente). Pienso en mí mismo cuando salí del instituto y en cuando salí de la uni, y francamente no querría quitarme esos años solo porque según que gente no sabe valorarlo.
El que acusa de titulitis o bien no tiene título, lo cual me huele a complejo de inferioridad, o bien lo tiene y entonces me apena grandemente porque pienso que esa persona realmente no ha sabido aprovechar su formación universitaria.
Releo y me suena elitista, y no es lo que pretendo. Es simplemente que más es más, lo mires como lo mires. Para según que sectores del mercado laboral será ciertamente inútil por excesivo. Para otros es un herramienta utilísima. Y para una persona con ansias de crecimiento personal nunca será demasiado.
Actualización 16-DIC-2006: Leyendo una entrada de BarraPunto sobre la creación de un nuevo colegio de informáticos en Galicia, he encontrado algunos comentarios brillantes (dos de los cuales han sido escritos por dos compañeros ingenieros, uno de caminos, y otra teleco); uno de ellos me ha hecho ver la luz sobre lo que todos conocemos con el intrusismo en informática, otro aporta bastantes argumentos en contra del típico FUD que hay contra la idea de colegios para informáticos, y el último aporta dos argumentos adicionales interesantes.
Intrusismo: Como ya he expresado en el principio de esta entrada en más de una ocasión, no estoy en contra del intrusismo, es algo inevitable y que no se puede prohibir (excepto en los casos citados), pero aún así creo que deberíamos coincidir todos en que es algo que no se debe fomentar, por supuesto, e incluso que debería desfomentarse, ya sólo desde el punto de vista de que supone una pérdida de dinero por parte del estado en la educación que han obtenido los que lo ejercen.
Colegiación no obligatoria: Citaré algunas frases del comentario:
(...)
Insisto por n-ésima vez, conozco decenas de abogados, arquitectos, biólogos, ingenieros, etc... no colegiados que trabajan como tal. Eso sí, no pueden firmar, para firmar ante la administración o ante un cliente que lo requiera hay que estar colegiado. No obstante, aún estando sin colegiar, se benefician del buen prestigio de tener un colectivo fuerte y con una cabeza visible al frente.
(...)
Siempre es positivo que los colegas de profesión estén unidos.
(...)
Responsabilidad y lucha anti-sistema: Para empezar, mucha gente se queja de que los colegios son malos en general porque imponen cuotas demasiado elevadas o alientan a mafias. Es posible que sea cierto, pero esa lucha habrá que emprenderla contra el grueso de colegios en general. Cerrándonos a tener un colegio lo que hacemos es ejercer esta lucha anti-sistema (que puede ser loable desde ciertos puntos de vista) sólo desde la rama de la informática, con lo que no disponemos al menos de las pocas ventajas que pueda suponer nuestro colegio y además estamos completamente indefensos ante otras ingenierías; puesto que, como reza este comentario, YA se están firmando/visando proyectos informáticos por colegiados de otras ingenierías, sólo por la exigencia de responsabilidad que requiere el cliente.
Actualización 25-ENE-2007: Me quito el sombrero ante esta entrada de IngenierosDePrimera:
¿Sabían ustedes que la Ingeniería Informática es una profesión no regulada?
¿Y eso… qué significa?
Significa que un proyecto informático no necesita tener un responsable titulado y colegiado que lo avale. Cualquier proyecto de Ingeniería (no informática) o Arquitectura tiene que ser supervisado y firmado por un Ingeniero o Arquitecto que da el visto bueno y realiza el seguimiento de su desarrollo para garantizar cosas como que se ajusta a las especificaciones, que sigue las normas y estándares.
Decimos, por ejemplo, que los arquitectos tienen las “atribuciones profesionales” para construir casas. Esto no quiere decir que el arquitecto ponga los ladrillos, pero sí que, si la casa se viene abajo o no tiene ventanas, el arquitecto es el responsable de ello. El Colegio de Arquitectos es quien controla a los arquitectos y, en caso de incompetencia manifiesta, expedienta o incluso expulsa del ejercicio profesional a quienes corresponda.
Es un sistema social que beneficia (a) a los arquitectos competentes y (b) a los clientes, que disponen de mecanismos de control de calidad.
Supongo que a estas alturas ya se están imaginando ustedes por qué suceden ciertas cosas en el desarrollo de proyectos informáticos: el Ave Madrid – Barcelona irá más lento de la cuenta por “incompatibilidad” de sistemas informáticos, la transacción bancaria no puede realizarse porque el sistema “se ha caído”, etc. Sin responsables; afortunadamente en castellano tenemos el modo impersonal para poder comunicar estas cosas.
Lo grave es que, a día de hoy, a falta de seis meses seis de la publicación del “Catálogo de Títulos Universitarios Oficiales”, el Estado Español no tiene la menor intención de que en él aparezca la Ingeniería Informática, ni de regular la profesión. Y las universidades parecen estar de acuerdo. A pesar de que España es el único país de la Unión Europea en esta situación.
¡¡¡¿¿¿Pero cómo puede ser esto???!!!
Serrat, en su Plany al mar dice: “per ignorància, per imprudència, per inconsciència i per mala llet.”. Supongo que debe ser por un poco de todo eso.
Pero ahora los informáticos se están movilizando desde la universidad, desde las asociaciones y desde Internet; no sólo están molestos con un Estado que no ha movido un dedo en más de 25 años de existencia “de facto” de la profesión y el sector, sino que empiezan a estar enfadados, quieren hacerse oír: quieren una profesión regulada, quieren atribuciones profesionales, quieren una titulación de primera incluida en el Catálogo Oficial de Títulos.
Vienen curvas.
Actualización 24-OCT-2007: Después de cosas como ésta empiezan a cobrar vida los postulados de la gente que reclama un colegio para la actividad profesional informática, sobre todo en estos casos (aunque cada vez la línea es más difusa, y mejor legislar para proteger).
Actualización 28-NOV-2007: La crisis se acrecienta. No se sabe si llegaremos a extremos más altos que éste.
Actualización 08-ABR-2009: Atención a la opinión del decano de mi ex-facultad acerca de lo que se acontece últimamente con respecto a esto (extraído de aquí):
Opinión de Javier Segovia, Decano de la Facultad de Informatica de la Universidad Politecnica de Madrid
Primera Parte
Hola a todos, queria daros mi impresión sobre el tema.
El objetivo final de nuestro colectivo es conseguir que se reconozcan las atribuciones de los informaticos.
Existen dos vias para ello. La primera es
reclamar que la profesion esta ya regulada, y de ahí las acciones legales
que se han tomado y los informes que se han contratado. No se si la via
tiene mucho futuro, es mas bien una via muerta si no es para conseguir las
fichas. Me explico. Si mañana viernes Zapatero se levanta con el pie
cambiado y dice en el consejo de ministros que estamos regulados por la Ley
12/1986, el efecto sobre la profesion seria nulo porque la ley 12/1986 nos
habilita para firmar proyectos, informes, tasaciones, etc., pero falta lo
fundamental: que otra ley, normativa, regulacion o lo que sea diga cuales
son los proyectos, informes, tasaciones, etc., relacionados con un tema
especifico que debemos firmar para entregar en la ventanilla de alguna
administracion. Como eso no existe, no habria ventanilla en la
administracion donde presentar nada tan solemnemente firmado. Os pongo el
ejemplo de teleco tecnica: si no existiesen la Ley 38/1999 y la Ley 10/2005
o los RD 2268/2004 y RD 944/2005 o la Orden ITC/270/2007 por ejemplo, los
telecos tecnicos por mucha 12/1986 que se les aplique no tendrian nada que
firmar, como nos pasaria a nosotros. Y ese es el principal argumento que han
tenido desde el gobierno para no hacerlo, hubieran aprobado algo sin
efectos. Por eso esta via no tiene muchos visos de ser exitosa.
La segunda via es la de la futura Ley de Servicios Profesionales relacionada
con la trasposicion de la directiva de servicios, que tiene una Ley aparte
llamada "Ley Paraguas". Esta via me la creo mas, bastante mas, y concuerda
con todo lo que hemos oido en nuestra direccion a los politicos sobre la
directiva, sean de un partido u otro, y en ella las fichas o pseudo fichas
tienen un papel importante que jugar. Os adjunto la directiva, el libro
blanco del gobierno sobre el tema, y un resumen de la directiva que ha
elaborado el ministerio de economia que es util para leerla y entenderla.
Creo que el follon que significa transponerla es de ordago porque, si no he
leido mal en algun otro sitio, tienen que revisar mas de 80 leyes y 370
reales decretos, entre las que probablemente esten las anteriores de los
telecos tecnicos.
Esta directiva es la llave para crear la necesidad de firma de un proyecto,
informe o tasacion. Y todo lo relacionado con informatica esta por regular
ya que lo que se excluye en ella por directivas anteriores que pueda parecer
relacionado (2002/19/CE a 2002/22/CE y 2002/58/CE) es relativo a
telecomunicaciones (telefonia, television, radio, etc).
Segunda Parte
La Ley de Servicios Profesionales y la Ley Paraguas van a retocar el marco
normativo de los colegios, y lo adaptara a la directiva. Y eso significa que
los colegios y asociaciones profesionales (Autoridad Competente según la
directiva) van a tener un papel aunque seguramente con otras funciones
distintas a las actuales. Si no interpreto mal por donde van los tiros, se
trataria de que no se pongan restricciones con respecto a la titulacion que
debe tener el que ejerce una actividad, sino que se pide que tenga las
competencias para ello que tendra que demostrar de alguna manera. Ya lo
decia tal cual el informe de la Comision Nacional de la Competencia, un
aviso a navegantes: "Es necesario romper con la unión automática de una
profesión y un título. Sin perjuicio de que en algunos casos el interés
general pueda justificar que una determinada profesión solo sea ejercida por
los poseedores de una titulación concreta, no debe ser ese el caso general,
sino la excepción, de tal forma que se permita que profesionales con
titulaciones diversas puedan competir en un mismo mercado", "Es preciso
quebrar la asociación automática de profesión titulada con Colegio
Profesional. Los motivos que justifican la exigencia de titulación no deben
ser automáticamente trasladables a la exigencia de colegiación. Una cosa es
restringir la entrada a un mercado (y limitar la competencia) alegando
razones de interés público que obligan a que el profesional posea unos
determinados conocimientos, y otra cosa es obligar a que, además de tener
una titulación, el profesional esté inscrito en un Colegio Profesional", "Es
necesario redefinir y acotar los fines y funciones de los Colegios
Profesionales, adoptando un enfoque desde el punto de vista de los
consumidores y no de los profesionales". Creo que en este sentido va el Art.
1. de la directiva que dice que los colegios realizaran la evaluación de las
competencias de los prestadores de servicios, la certificacion o evaluacion
de sus actividades y la elaboracion de cartas de calidad. Tambien dice que
seran los colegios los que elaboren codigos de conducta que deberan seguir
los prestadores de servicios (Art. 37), etc.
Para mi esta claro clarisimo que lo que pretendemos se va a reflejar en esa
Ley o leyes y su desarrollo normativo posterior. Y las fichas (pseudo o
full) aquí adquieren su importancia mayor, mucho mayor que en lo referente a
su vertiente academica de herramienta de verificacion de titulos, porque a
la hora de decidir si nuestros ingenieros tienen una determinada competencia
para que su empresa preste un servicio proyectado por ellos sera la ficha de
su titulacion lo que lo va a aclarar. Ese es el verdadero valor de la ficha,
y en este sentido yo pongo una cruz en "objetivo conseguido", sea pseudo
ficha o full, tenga reserva de nombre o no, falte una competencia
transversal o no (si fuera competencia tecnica que pudiera tener relacion
con una atribucion seria otro caso, pero no lo es). Tambien tenemos que
tener claro que si una titulacion X que no es en informatica tiene una
determinada competencia adecuada para un trabajo, sus titulados valdran
tanto como los nuestros para ello, tenga su titulacion ficha o no, sea esta
pseudo o full, tengamos nosotros una competencia mas transversal o no.
Tercera Parte
Según mis noticias, el gobierno se reunio tiempo atras con los Colegios para
tratar de ver como les afecta. Es importante entender que significa esto
para ver si nos tenemos que poner nerviosos o no, y mandar o no la gente a
las barricadas. Por lo que se, se trataba simplemente de identificar la
normativa colegial potencialmente afectada por la directiva, es decir,
estatutos, reglamentos de régimen interior, etc., identificar todos los
procedimientos informáticos y simplificarlos, incluir todos los trámites que
se realizan ante los Colegios con el fin de que todos ellos, incluso la
inscripción en el Colegio, se puedan realizar de forma telemática, etc., en
resumen, evaluar en cada colegio su compatibilidad administrativa con las
disposiciones de la directiva. Ignoro si se han reunido para algo mas.
Os adjunto tambien el informe de 2007 del Grupo de Trabajo para la
transposicion de la Directiva de Servicios. Van fuera de fechas y les quedan
muchas cosas por hacer. Hay ya un borrador de anteproyecto de la Ley
Paraguas, y se esta discutiendo incluso la definicion del concepto de
“profesión regulada”. Estan en ello los politicos, y es en los politicos
donde hay que influir. ¿Cómo se influye? Es un error pensar que un coche
anda solo porque le ponemos una rueda; hacen falta las otras tres, y el
motor. Con que falte una sola de esas cosas el coche no va a andar. Todo
tiene que estar engranado. En lo que hemos conseguido nos hemos movido todos
pero dudo que ninguno de nosotros conozca el conjunto de todo lo que ha
hecho que el coche ande. Todo es fundamental y nada lo es. Han habido muchas
actividades publicas pero tambien muchas actividades silenciosas y anonimas,
muchas mas de las que parece. Pero ahora toca trabajar en despachos, visitar
politicos, visitar autoridades de CCAA que tienen mucho que decir, visitar
Colegios de otras profesiones. Y hay que luchar ahora con la razon, no con
la fuerza.
Y la razon no es reclamar los derechos de los informaticos, es reclamar que
los servicios informaticos se hagan con calidad. Una manifestacion de
estudiantes es importante y tiene efecto si lo que se reclama tiene
consecuencias academicas. Si lo que se reclama tiene efectos profesionales
quienes deberian manifestarse son los profesionales, tanto los que emplean
que quieren calidad para vender como los empleados que la aseguran con su
trabajo, y los usuarios finales que estan cansados de productos que no
funcionan. Pero tampoco asi creo en su efectividad. Es mucho mas importante
aquí una llamada a un politico del presidente de la patronal del sector o el
de un sindicato o el de la asociacion de consumidores que no una
manifestacion de 1000 estudiantes. Esa es la direccion a trabajar.
Ya se estan moviendo los politicos de varios partidos (incluso del gobierno)
y estan ofreciendo su ayuda otra vez. Si hacemos manifestaciones o
comunicados en contra o echando por tierra lo que nos han conseguido hasta
ahora (todos han puesto una rueda, tuerca o bombin fundamental en el coche y
por tanto lo hacen suyo), y que tiene un valor que todavia no sabemos
calcular, me parece que nos van a decir que para este agradecimiento no van
a perder mas el tiempo otra vez.
Las europeas estan demasiado cerca para protestar masivamente por una
transposicion de la directiva que todavia no habran hecho por esas fechas, y
lo unico que provocariamos es quitar votos al gobierno al salir en los
telediarios con las pancartas, con lo cual el daño ya estaria hecho y el
tiro gastado. Hay que medirlo.
Un abrazo!
Javier Segovia
Decano/Dean
Tlf:+34-91-3367400
Fax:+34-91-3367412
Direccion/Address:
Facultad de Informatica
Campus de Montegancedo
Universidad Politecnica de Madrid
Boadilla del Monte, 28660
Madrid, Spain
--------------------------------------------------------------
Aquí os lo dejo:
Sí, esto es un antiFUD. Sé que muchos de vosotros estáis super de acuerdo con los colegios, y también sé que otros muchos matarían para que no se construyera una nueva "mafia".
Bien, pues yo apelo a que utilicéis vuestro intelecto de una maldita vez. Vale ya de FUD's. Se acabaron los comentarios del tipo "¡fuera los intrusos!" o bien "¡abajo las mafias!".
Voy a intentar haceros ver, si os interesa claro, que uno se puede posicionar en un punto intermedio en cuanto a la opinión de si los colegios deberían existir o no. Es decir, EL GRIS EXISTE, vale ya de blancos y de negros, no seamos como la mayoría de los borregos españolitos que votan en binario.
Para empezar quiero defenderme de las típicas falacias:
- Un colegio no impondría ninguna restricción al software libre. Los colegios, desde mi punto de vista, no han de verse desde un ángulo desde el cual cualquier individuo de la sociedad de nuestro país necesitase una licencia para escribir software. Sinceramente, desconozco si existen colegios profesionales de periodismo, pero argumentar esto sería como decir que su existencia prohibiría lo que hoy conocemos por la "blogosfera".
Un colegio no ilegalizaría a los profesionales informáticos sin titulación oficial. NO NO y rotundamente NO. Si eres ingeniero, no creas que los colegios serían la solución al intrusismo. Si eres informático y no tienes titulación, ¡no des por hecho que con su existencia se te ha acabado el trabajo! Es evidente que las empresas, si quieren minimizar riesgos, deberían limitarse a estas titulaciones para contratar, pues aportan una certificación oficial de unos conocimientos mínimos del trabajador. Pero no es tarea del gobierno ni del estado regular los comportamientos de las empresas. Igual que no hay un carnet para ser periodista (y esto es de lo que, al parecer, se quejan muchos profesionales de este secor, al ver que muchos "intrusos" son contratados para ejercer de puestos típicamente ostentados por ellos), tampoco se pretende que haya un carnet para ser informático.
NO OBSTANTE, hay ciertas circunstancias en la que no sólo están en juego los beneficios de una empresa, e incluso en algunas de éstas, no existe el papel de la empresa privada como tal. Y es aquí donde entran en juego los colegios, EMHO, ya que sí vendrían a regular esta serie de circunstancias que yo considero LEGÍTIMAS en las que sí deberíamos restringir el ejercicio de la profesión, y son solamente tres:
- A la hora de la contratación de personal con responsabilidades en las áreas de las tecnologías de la información, si y sólo si, ésta se realiza por cualquier entidad que sea pública, o bien, que esté financiada con dinero público.
- En cualquier caso en el que las actividades derivadas del ejercicio de la profesión puedan llegar a estar implicadas circunstancias de responsabilidad civil o penal, o bien puedan acarrear daños o perjuicios a terceros.
- Cualquier actividad de peritaje o auditoría inspirada en la actividad profesional de los organismos directa o indirectamente relacionados con la justicia del estado.
Estas tres circunstancias están basadas en el principio de que la sociedad, los ciudadanos, sí tienen derecho a exigir ese mínimo certificado de calidad del que he hablado antes. Ese certificado que las empresas privadas pueden valorar y, si quieren, descartar, por preferir un ahorro de costes.- Un colegio no impondría una tasa indiscriminada a todos los profesionales titulados del sector. Al igual que un licenciado en derecho no está obligado a pagar al colegio de abogados para ejercer su profesión, un informático tampoco. Es cuando el jurista desea ejercer la abogacía cuando necesita colegiarse, porque la abogacía es una actividad ligada plenamente al estado, y más concreto, al poder judicial del estado. Pero un licenciado en derecho tiene un abanico muy amplio de profesiones a ejercer: técnico de recursos humanos, asesor, notario, etc. Del mismo modo ocurriría con los colegios de informáticos: si un licenciado/ingeniero/doctor está interesado en a) ejercer en un cargo público, b) emprender un ejercicio profesional que pueda implicar responsabilidades civiles o penales, c) actuar de perito o auditor en un juicio, pues sólo tendría que colegiarse. También podrían colegiarse profesionales que no se beneficiasen directamente de estas tres posibilidades, pero que sí estuvieran interesados en recibir algún tipo de seguro, asesoramiento técnico, legal, o cualquier otro servicio de valor añadido.
Otras competencias adicionales, más subordinadas, que podrían tener los colegios:
- Establecer sistemas de gestión y regulación de la "basura informática". Consistiría en gestionar y regular los desperdicios informáticos que generan las empresas. También podrían crearse sistemas de "aprovechamiento" de estos medios, mediante envíos de equipos y material al tercer mundo, etc.
- Crear aplicaciones y bases de datos para la regulación del empleo/desempleo, bolsas de trabajo, etc.
- Establecer precios orientativos de las típicas tareas de administración de sistemas, e incluso de informar sobre las mejores medidas de medición y baremos sobre el tiempo y costes de los proyectos de desarrollo.
- Fomentar el software libre. Sí, pienso que los colegios podrían contratar personal que se dedicase a hacer auditorías en los estamentos públicos de manera que se hiciese una migración gradual de todos los soportes a software libre.
- Gestión de cánones. Si nuestro querido canon de los CD's sigue sin ilegalizarse, podríamos intentar hacer que el colegio de informáticos adquiriese la competencia de actuar de intermediario entre las entidades de gestión y los profesionales que sí utilizan los medios digitales para algo distinto que la copia privada. Podrían expenderse licencias a las administraciones, autónomos y empresas privadas dedicadas a que no pagasen el canon. E incluso podría permitirse a los ciudadanos de a pie que quisiesen reclamar el importe "robado", que accedieran a un pequeño trámite mediante el cual pudieran demostrar que sus soportes no han sido utilizados para la copia privada.
- Luchar contra el spam. Actuar como una "fiscalía" para casos de correo electrónico comercial no solicitado.
- Otras actividades relacionadas con la Agencia de Protección de Datos, por ejemplo, relativas al tratamiento digital de los datos personales.
Tengo que confesar que, a pesar de lo elaborado de mi tesis o propuesta, me siguen quedando dudas que me gustaría poder debatir. Por ejemplo, está claro que dentro de la esfera de casos englobados en el punto 2.(b) mencionado arriba cabría citar el ejemplo del desarrollo de los sistemas de seguridad software de una central nuclear, pero ¿y el software de un banco el cual pudiera, vista comprometida su seguridad, provocar daños económicos a sus clientes, los cuales son "terceros" puesto que son totalmente ajenos al contrato en el que se negocia el desarrollo del software de su entidad bancaria?
Actualización: La última entrada en BarraPunto sobre este tema es ¿A qué Asociación de informáticos me suscribo? y después de leerla he descubierto cosas interesantes. La primera es que sigue existiendo el blanco y el negro en barrapunto: los ingenieros que, cabreados por el intrusismo, quieren poner un coto a la profesión; y los no titulados que creen que son los únicos que saben trabajar, que los colegios son mafias y no sirven para nada. También he recopilado algunos enlaces de casos prácticos sobre este tema:
ALI: Asociacion de Doctores Licenciados e Ingenieros en Informática de España. El contraejemplo. Esperemos que esta gente no llegue nunca a nada. Sólo con ver su horripilante web se puede comprobar de lo que son capaces.
COIIPA: Colegio Oficial de Ingenieros en Informática del Principado de Asturias. Así es como deberían de ser todos los colegios. Tienen atribuidas una serie de funciones no intrusivas, admiten que no pretenden luchar contra el intrusismo sino sólo defenderse, y más cuestiones interesantes que aparecen en el documento de Preguntas Frecuentes sobre el colegio.
Actualización 20-NOV-2006: Reproduzco un comentario interesante de BarraPunto en una noticia de hace unos días:
Referente a los títulos, creo que se tiende a olvidar que sólo es un acreditativo de una institución que indica que has superado las pruebas necesarias para tenerlo. Nada más. Igual que el carné de conducir. Hay muy buenos conductores sin carné que no tienen accidentes y pasan desapercibidos sin pagar absolutamente nada y otros no tan buenos que tienen carne y tienen multas y accidentes. El problema viene de todo el rango entre un extremo y el otro. Pues lo mismo con los colegios. Hay profesionales, hay gentuza y gente entre ambos extremos. Yo creo que SÍ debería haber colegio, no para garantizar sueldos, sino simplemente para regular las competencias y las responsabilidades de una profesión que se ha convertido en un escudo para la incompetencia de las demás. Me explico, un aparejador tiene una regulación de lo que puede o no firmar, la responsabilidad de lo que tiene que hacer en una obra y un seguro para responder civilmente por los fallos que puede tener. Una grieta en una casa y un tío debe decir porqué. ¿Quién no ha ido a un banco y le han dicho alguna vez que los ordenadores no funcionan? ¿O las páginas web? ¿O el ordenador de la biblioteca? ¿O han cambiado sus datos? La gente de a pie no tiene porqué soportar eso y el señor del banco no tiene porqué dar mala imagen: TÚ debes pagar por ello si tu programa no cumplía las regulaciones pertinentes.
Y otro más, que habla sobre ese concepto llamado 'titulitis':
Cada vez que sale la titulitis a colación me pregunto si soy el único que ha tenido la suerte de trabajar con colegas recién escudillados de la superior y el típico personaje "con toda la experiencia que da el trabajo" y apreciar la diferencia.
Sí, la experiencia cuenta, pero el título no detrae. En todo caso aporta. Y en la mayoría de los casos se nota. Se nota en la amplitud de miras, en los conocimientos generalistas de muchas ramas de la informática; se nota en la calidad del código, en la claridad y en los principios de ingeniería de software que un programador novel ya imprime en sus primeras tareas.
Tal vez sea que mi universidad enseña decentemente la carrera, o es que en barrapunto el tener el título es un estigma, pero cada vez que alguien defiende la experiencia y acusa de titulitis yo pienso "dentro de 3 años el ingeniero tendrá ambas cosas" y quieras que no, 5 años de informática bien enseñada dejan poso para toda la vida. La universidad no es aprender java y las tecnologías de moda, es mucho más que eso (o más bien otra cosa completamente diferente). Pienso en mí mismo cuando salí del instituto y en cuando salí de la uni, y francamente no querría quitarme esos años solo porque según que gente no sabe valorarlo.
El que acusa de titulitis o bien no tiene título, lo cual me huele a complejo de inferioridad, o bien lo tiene y entonces me apena grandemente porque pienso que esa persona realmente no ha sabido aprovechar su formación universitaria.
Releo y me suena elitista, y no es lo que pretendo. Es simplemente que más es más, lo mires como lo mires. Para según que sectores del mercado laboral será ciertamente inútil por excesivo. Para otros es un herramienta utilísima. Y para una persona con ansias de crecimiento personal nunca será demasiado.
Actualización 16-DIC-2006: Leyendo una entrada de BarraPunto sobre la creación de un nuevo colegio de informáticos en Galicia, he encontrado algunos comentarios brillantes (dos de los cuales han sido escritos por dos compañeros ingenieros, uno de caminos, y otra teleco); uno de ellos me ha hecho ver la luz sobre lo que todos conocemos con el intrusismo en informática, otro aporta bastantes argumentos en contra del típico FUD que hay contra la idea de colegios para informáticos, y el último aporta dos argumentos adicionales interesantes.
Intrusismo: Como ya he expresado en el principio de esta entrada en más de una ocasión, no estoy en contra del intrusismo, es algo inevitable y que no se puede prohibir (excepto en los casos citados), pero aún así creo que deberíamos coincidir todos en que es algo que no se debe fomentar, por supuesto, e incluso que debería desfomentarse, ya sólo desde el punto de vista de que supone una pérdida de dinero por parte del estado en la educación que han obtenido los que lo ejercen.
Colegiación no obligatoria: Citaré algunas frases del comentario:
(...)
Insisto por n-ésima vez, conozco decenas de abogados, arquitectos, biólogos, ingenieros, etc... no colegiados que trabajan como tal. Eso sí, no pueden firmar, para firmar ante la administración o ante un cliente que lo requiera hay que estar colegiado. No obstante, aún estando sin colegiar, se benefician del buen prestigio de tener un colectivo fuerte y con una cabeza visible al frente.
(...)
Siempre es positivo que los colegas de profesión estén unidos.
(...)
Responsabilidad y lucha anti-sistema: Para empezar, mucha gente se queja de que los colegios son malos en general porque imponen cuotas demasiado elevadas o alientan a mafias. Es posible que sea cierto, pero esa lucha habrá que emprenderla contra el grueso de colegios en general. Cerrándonos a tener un colegio lo que hacemos es ejercer esta lucha anti-sistema (que puede ser loable desde ciertos puntos de vista) sólo desde la rama de la informática, con lo que no disponemos al menos de las pocas ventajas que pueda suponer nuestro colegio y además estamos completamente indefensos ante otras ingenierías; puesto que, como reza este comentario, YA se están firmando/visando proyectos informáticos por colegiados de otras ingenierías, sólo por la exigencia de responsabilidad que requiere el cliente.
Actualización 25-ENE-2007: Me quito el sombrero ante esta entrada de IngenierosDePrimera:
¿Sabían ustedes que la Ingeniería Informática es una profesión no regulada?
¿Y eso… qué significa?
Significa que un proyecto informático no necesita tener un responsable titulado y colegiado que lo avale. Cualquier proyecto de Ingeniería (no informática) o Arquitectura tiene que ser supervisado y firmado por un Ingeniero o Arquitecto que da el visto bueno y realiza el seguimiento de su desarrollo para garantizar cosas como que se ajusta a las especificaciones, que sigue las normas y estándares.
Decimos, por ejemplo, que los arquitectos tienen las “atribuciones profesionales” para construir casas. Esto no quiere decir que el arquitecto ponga los ladrillos, pero sí que, si la casa se viene abajo o no tiene ventanas, el arquitecto es el responsable de ello. El Colegio de Arquitectos es quien controla a los arquitectos y, en caso de incompetencia manifiesta, expedienta o incluso expulsa del ejercicio profesional a quienes corresponda.
Es un sistema social que beneficia (a) a los arquitectos competentes y (b) a los clientes, que disponen de mecanismos de control de calidad.
Supongo que a estas alturas ya se están imaginando ustedes por qué suceden ciertas cosas en el desarrollo de proyectos informáticos: el Ave Madrid – Barcelona irá más lento de la cuenta por “incompatibilidad” de sistemas informáticos, la transacción bancaria no puede realizarse porque el sistema “se ha caído”, etc. Sin responsables; afortunadamente en castellano tenemos el modo impersonal para poder comunicar estas cosas.
Lo grave es que, a día de hoy, a falta de seis meses seis de la publicación del “Catálogo de Títulos Universitarios Oficiales”, el Estado Español no tiene la menor intención de que en él aparezca la Ingeniería Informática, ni de regular la profesión. Y las universidades parecen estar de acuerdo. A pesar de que España es el único país de la Unión Europea en esta situación.
¡¡¡¿¿¿Pero cómo puede ser esto???!!!
Serrat, en su Plany al mar dice: “per ignorància, per imprudència, per inconsciència i per mala llet.”. Supongo que debe ser por un poco de todo eso.
Pero ahora los informáticos se están movilizando desde la universidad, desde las asociaciones y desde Internet; no sólo están molestos con un Estado que no ha movido un dedo en más de 25 años de existencia “de facto” de la profesión y el sector, sino que empiezan a estar enfadados, quieren hacerse oír: quieren una profesión regulada, quieren atribuciones profesionales, quieren una titulación de primera incluida en el Catálogo Oficial de Títulos.
Vienen curvas.
Actualización 24-OCT-2007: Después de cosas como ésta empiezan a cobrar vida los postulados de la gente que reclama un colegio para la actividad profesional informática, sobre todo en estos casos (aunque cada vez la línea es más difusa, y mejor legislar para proteger).
Actualización 28-NOV-2007: La crisis se acrecienta. No se sabe si llegaremos a extremos más altos que éste.
Actualización 08-ABR-2009: Atención a la opinión del decano de mi ex-facultad acerca de lo que se acontece últimamente con respecto a esto (extraído de aquí):
Opinión de Javier Segovia, Decano de la Facultad de Informatica de la Universidad Politecnica de Madrid
Primera Parte
Hola a todos, queria daros mi impresión sobre el tema.
El objetivo final de nuestro colectivo es conseguir que se reconozcan las atribuciones de los informaticos.
Existen dos vias para ello. La primera es
reclamar que la profesion esta ya regulada, y de ahí las acciones legales
que se han tomado y los informes que se han contratado. No se si la via
tiene mucho futuro, es mas bien una via muerta si no es para conseguir las
fichas. Me explico. Si mañana viernes Zapatero se levanta con el pie
cambiado y dice en el consejo de ministros que estamos regulados por la Ley
12/1986, el efecto sobre la profesion seria nulo porque la ley 12/1986 nos
habilita para firmar proyectos, informes, tasaciones, etc., pero falta lo
fundamental: que otra ley, normativa, regulacion o lo que sea diga cuales
son los proyectos, informes, tasaciones, etc., relacionados con un tema
especifico que debemos firmar para entregar en la ventanilla de alguna
administracion. Como eso no existe, no habria ventanilla en la
administracion donde presentar nada tan solemnemente firmado. Os pongo el
ejemplo de teleco tecnica: si no existiesen la Ley 38/1999 y la Ley 10/2005
o los RD 2268/2004 y RD 944/2005 o la Orden ITC/270/2007 por ejemplo, los
telecos tecnicos por mucha 12/1986 que se les aplique no tendrian nada que
firmar, como nos pasaria a nosotros. Y ese es el principal argumento que han
tenido desde el gobierno para no hacerlo, hubieran aprobado algo sin
efectos. Por eso esta via no tiene muchos visos de ser exitosa.
La segunda via es la de la futura Ley de Servicios Profesionales relacionada
con la trasposicion de la directiva de servicios, que tiene una Ley aparte
llamada "Ley Paraguas". Esta via me la creo mas, bastante mas, y concuerda
con todo lo que hemos oido en nuestra direccion a los politicos sobre la
directiva, sean de un partido u otro, y en ella las fichas o pseudo fichas
tienen un papel importante que jugar. Os adjunto la directiva, el libro
blanco del gobierno sobre el tema, y un resumen de la directiva que ha
elaborado el ministerio de economia que es util para leerla y entenderla.
Creo que el follon que significa transponerla es de ordago porque, si no he
leido mal en algun otro sitio, tienen que revisar mas de 80 leyes y 370
reales decretos, entre las que probablemente esten las anteriores de los
telecos tecnicos.
Esta directiva es la llave para crear la necesidad de firma de un proyecto,
informe o tasacion. Y todo lo relacionado con informatica esta por regular
ya que lo que se excluye en ella por directivas anteriores que pueda parecer
relacionado (2002/19/CE a 2002/22/CE y 2002/58/CE) es relativo a
telecomunicaciones (telefonia, television, radio, etc).
Segunda Parte
La Ley de Servicios Profesionales y la Ley Paraguas van a retocar el marco
normativo de los colegios, y lo adaptara a la directiva. Y eso significa que
los colegios y asociaciones profesionales (Autoridad Competente según la
directiva) van a tener un papel aunque seguramente con otras funciones
distintas a las actuales. Si no interpreto mal por donde van los tiros, se
trataria de que no se pongan restricciones con respecto a la titulacion que
debe tener el que ejerce una actividad, sino que se pide que tenga las
competencias para ello que tendra que demostrar de alguna manera. Ya lo
decia tal cual el informe de la Comision Nacional de la Competencia, un
aviso a navegantes: "Es necesario romper con la unión automática de una
profesión y un título. Sin perjuicio de que en algunos casos el interés
general pueda justificar que una determinada profesión solo sea ejercida por
los poseedores de una titulación concreta, no debe ser ese el caso general,
sino la excepción, de tal forma que se permita que profesionales con
titulaciones diversas puedan competir en un mismo mercado", "Es preciso
quebrar la asociación automática de profesión titulada con Colegio
Profesional. Los motivos que justifican la exigencia de titulación no deben
ser automáticamente trasladables a la exigencia de colegiación. Una cosa es
restringir la entrada a un mercado (y limitar la competencia) alegando
razones de interés público que obligan a que el profesional posea unos
determinados conocimientos, y otra cosa es obligar a que, además de tener
una titulación, el profesional esté inscrito en un Colegio Profesional", "Es
necesario redefinir y acotar los fines y funciones de los Colegios
Profesionales, adoptando un enfoque desde el punto de vista de los
consumidores y no de los profesionales". Creo que en este sentido va el Art.
1. de la directiva que dice que los colegios realizaran la evaluación de las
competencias de los prestadores de servicios, la certificacion o evaluacion
de sus actividades y la elaboracion de cartas de calidad. Tambien dice que
seran los colegios los que elaboren codigos de conducta que deberan seguir
los prestadores de servicios (Art. 37), etc.
Para mi esta claro clarisimo que lo que pretendemos se va a reflejar en esa
Ley o leyes y su desarrollo normativo posterior. Y las fichas (pseudo o
full) aquí adquieren su importancia mayor, mucho mayor que en lo referente a
su vertiente academica de herramienta de verificacion de titulos, porque a
la hora de decidir si nuestros ingenieros tienen una determinada competencia
para que su empresa preste un servicio proyectado por ellos sera la ficha de
su titulacion lo que lo va a aclarar. Ese es el verdadero valor de la ficha,
y en este sentido yo pongo una cruz en "objetivo conseguido", sea pseudo
ficha o full, tenga reserva de nombre o no, falte una competencia
transversal o no (si fuera competencia tecnica que pudiera tener relacion
con una atribucion seria otro caso, pero no lo es). Tambien tenemos que
tener claro que si una titulacion X que no es en informatica tiene una
determinada competencia adecuada para un trabajo, sus titulados valdran
tanto como los nuestros para ello, tenga su titulacion ficha o no, sea esta
pseudo o full, tengamos nosotros una competencia mas transversal o no.
Tercera Parte
Según mis noticias, el gobierno se reunio tiempo atras con los Colegios para
tratar de ver como les afecta. Es importante entender que significa esto
para ver si nos tenemos que poner nerviosos o no, y mandar o no la gente a
las barricadas. Por lo que se, se trataba simplemente de identificar la
normativa colegial potencialmente afectada por la directiva, es decir,
estatutos, reglamentos de régimen interior, etc., identificar todos los
procedimientos informáticos y simplificarlos, incluir todos los trámites que
se realizan ante los Colegios con el fin de que todos ellos, incluso la
inscripción en el Colegio, se puedan realizar de forma telemática, etc., en
resumen, evaluar en cada colegio su compatibilidad administrativa con las
disposiciones de la directiva. Ignoro si se han reunido para algo mas.
Os adjunto tambien el informe de 2007 del Grupo de Trabajo para la
transposicion de la Directiva de Servicios. Van fuera de fechas y les quedan
muchas cosas por hacer. Hay ya un borrador de anteproyecto de la Ley
Paraguas, y se esta discutiendo incluso la definicion del concepto de
“profesión regulada”. Estan en ello los politicos, y es en los politicos
donde hay que influir. ¿Cómo se influye? Es un error pensar que un coche
anda solo porque le ponemos una rueda; hacen falta las otras tres, y el
motor. Con que falte una sola de esas cosas el coche no va a andar. Todo
tiene que estar engranado. En lo que hemos conseguido nos hemos movido todos
pero dudo que ninguno de nosotros conozca el conjunto de todo lo que ha
hecho que el coche ande. Todo es fundamental y nada lo es. Han habido muchas
actividades publicas pero tambien muchas actividades silenciosas y anonimas,
muchas mas de las que parece. Pero ahora toca trabajar en despachos, visitar
politicos, visitar autoridades de CCAA que tienen mucho que decir, visitar
Colegios de otras profesiones. Y hay que luchar ahora con la razon, no con
la fuerza.
Y la razon no es reclamar los derechos de los informaticos, es reclamar que
los servicios informaticos se hagan con calidad. Una manifestacion de
estudiantes es importante y tiene efecto si lo que se reclama tiene
consecuencias academicas. Si lo que se reclama tiene efectos profesionales
quienes deberian manifestarse son los profesionales, tanto los que emplean
que quieren calidad para vender como los empleados que la aseguran con su
trabajo, y los usuarios finales que estan cansados de productos que no
funcionan. Pero tampoco asi creo en su efectividad. Es mucho mas importante
aquí una llamada a un politico del presidente de la patronal del sector o el
de un sindicato o el de la asociacion de consumidores que no una
manifestacion de 1000 estudiantes. Esa es la direccion a trabajar.
Ya se estan moviendo los politicos de varios partidos (incluso del gobierno)
y estan ofreciendo su ayuda otra vez. Si hacemos manifestaciones o
comunicados en contra o echando por tierra lo que nos han conseguido hasta
ahora (todos han puesto una rueda, tuerca o bombin fundamental en el coche y
por tanto lo hacen suyo), y que tiene un valor que todavia no sabemos
calcular, me parece que nos van a decir que para este agradecimiento no van
a perder mas el tiempo otra vez.
Las europeas estan demasiado cerca para protestar masivamente por una
transposicion de la directiva que todavia no habran hecho por esas fechas, y
lo unico que provocariamos es quitar votos al gobierno al salir en los
telediarios con las pancartas, con lo cual el daño ya estaria hecho y el
tiro gastado. Hay que medirlo.
Un abrazo!
Javier Segovia
Decano/Dean
Tlf:+34-91-3367400
Fax:+34-91-3367412
Direccion/Address:
Facultad de Informatica
Campus de Montegancedo
Universidad Politecnica de Madrid
Boadilla del Monte, 28660
Madrid, Spain
--------------------------------------------------------------
Labels: General, Ingenieria, SoftwareLibre
