Yesterday I worked hard on rebuilding my .NET Framework library to load IFC files. Since last rebuild done at the end of 2008 - when I handled EXPRESS file compatibility with 2X3 ALPHA version, I achieved the compatibility with the final release of IFC 4, delivered in March 12th 2013.
My project, the IFCEntityCodeGenerator written completely in Visual Basic .NET for .NET Framework 4.0 (but it also builds with .NET Framework 1.0/1.1/2.0/3.0/3.5 and maybe 4.5), is able to produce an unique Visual Basic module source code ready to include in any project you need to load IFC files with.
The IFCEntityCodeGenerator is being able to load completely the EXPRESS IFC schema and outputs a file (its size is 1,7 MB with the IFC4 EXPRESS schema) which includes all the enumerations, the enumeration conversions from strings, and more than a thousand classes being able to parse an IFC STEP file from file.
At now the project cannot read from an XML file stream (.ifcxml file format), nor it cannot save to file the same IFC STEP file, but I hope to do it soon, in order to support more packaging formats and delivering the ability to export some IFC datas from application software of my customers.
For more information about IFC and BIM technology, please check here.
In passato ho provato invano ad usare la conversione automatica di jUpgrade, ma niente da fare. Ci ho lavorato un po' dietro per far si che la miscellanea di codici Javascript, php e quant'altro riescano, ma ci ho rinunciato per un paio di server che ho in gestione da tempo. C'è sempre qualcosa che si mette di traverso, anche se sarebbe una gran cosa. L'unica è quella di farla fare a qualcuno che è capace, però sicuramente avrete bisogno di:
cedergli temporaneamente le credenziali di accesso al sito e/o al server, con la necessità di cambiare successivamente, una volta che il CMS sarà stato aggiornato alla versione più nuova
cedergli dei danari
...insomma, un lavoro da veri smanettoni, sicuramente più smanettoni di me!
jUpgradenon è comunque l'unico tool. Se cercate bene tra le Joomla! Extensions, tra quelle di migrazione e considerando solo quelle gratuite, ci sarebbe da dare una chance anche a J2XML; lo proverò sicuramente in futuro, anche se, stando alle specifiche indicate sul sito di E-Shiol, non fa molto di più della conversione che suggerisco io sotto.
Partiamo pertanto dal presupposto che abbiate tra le mani un sito sviluppato qualche anno fa con Joomla! 1.5 e che vogliate convertirlo ad una versione più moderna (2.5.x o 3.x) per uno qualsiasi dei seguenti motivi:
Joomla! 1.5.x è dichiarato "obsoleto" e non più supportato dalla comunità che lo sviluppa e lo manutenziona
il vostro sito ha subito un attacco sfruttando proprio qualche vulnerabilità di Joomla!
volete caricare un template molto più piacevole
volete ristrutturare il sito reorganizzando gli stessi contenuti attraverso nuovi menù o nuovi moduli
Ecco la mia modalità quick-and-dirty, molto dirty e poco quick. Diciamo che riesco a travasare i "soli" contenuti, cioè tutti gli articoli, che può essere già di suo una manna dal cielo.
Supponiamo che le tabelle utilizzate dentro Joomla! 1.5.x avessero come prefisso jos_, visto che era il prefisso predefinito fino alla versione 1.5. A partire dalle versioni successive il prefisso è parametrico ed è generato casualmente all'atto dell'installazione di Joomla!, questo per cercare di arginare qualche eventuale attacco.
Io ho provato un po' a vedere quante e quali sono le tabelle che si riescono a migrare da un database all'altro, ma esistono parecchie differenze, sia sui nomi delle tabelle, sull'esistenza di tabelle, sul nome di alcuni campi all'interno delle tabelle, nonché sulla presenza dei campi stessi. Si sono salvate solamente 3 tabelle in questa conversione:
travasare jos_content to yyyyy_content;
travasare xxx_contact_details to yyyyy_contact_details;
travasare xxx_menu_types to yyy_menu_types, ricordandosi di togliere il primo record visto che esiste già un record con ID=1 nella tabella yyyyy_menu_types;
loggarsi dentro l'area amministrativa di Joomla! ed attribuire a tutti gli articoli lo stesso livello di accesso, la lingua ed una categoria, tanto per avere i record correttamente impostati
Da questo punto in poi, rimboccatevi le mani e cominciate a fare tutto quello che fareste con un sito nuovo, cioè:
ricostruire i menu
ricaricare il template grafico
ricaricare plugin e moduli di cui non potete fare a meno
Ma non era proprio questa l'intezione iniziale? Ristrutturare il sito salvando i contenuti?
Di tanto in tanto può succedere di non riuscire a modificare e cancellare file da cartelle via FTP. Capita su server Windows dove i file o le cartelle risultano in uso da parte di qualche processo, per cui basterà attendere il rilascio del file o, nel caso più estremo, basterà riavviare il server e ritrovarsi i file liberi per ogni tipo di modifica.
Su server Linux si può presentare un altro scenario: non siete più in grado di rimuovere file e cartelle dentro l'area FTP, semplicemente perché l'owner dei file e delle cartelle non siete voi e il tipo di previlegi su quei file non vi consente di modificarli.
A me è successo proprio ieri, quando ho avuto la brillante idea di effettuare l'aggiornamento di un'installazione di Joomla! direttamente dall'area amministrativa di Joomla! stesso. Tra me ho pensato: "C'è la detezione automatica di una versione più nuova, perché non andare fino in fondo e fargli applicare l'aggiornamento con un solo click?".
Joomla! si è messo a scaricare l'aggiornamento, che da server a server su un buon fornitore di housing è una bazzeccola in termini di secondi, considerata la banda presente, solo che alla sua decompressione e riposizionamento dei file nelle cartelle, segnala il fatto che non riesce a completare la cosa in un percorso relativo.
"Bene" ho pensato. E' sufficiente mettersi a mano via FTP e fare l'upload di tutti i file ottenuti dal packaging Joomla_2.5.x_to_2.5.14-Stable-Patch_Package e sovrascriverli si a file della vecchia versione che a quelli nuovi che l'aggiornamento automatico ha provato a fare. Purtroppo il processo di aggiornamento si ferma su alcuni file che risulta impossibile eliminare perché:
questi file hanno come owner apache (proprio lo user in esecuzione da parte dell'aggiornamento automatico di Joomla)
questi file e cartelle hanno come previlegi in scrittura rispettivamente 644 e 755, pertanto si possono solo leggere e non modificare via FTP, visto che ci si logga con le credenziali FTP del proprietario del sito, d'ora in poi, a titolo di esempio, mywebsiteowner
Dopo averle provate un po' tutte, prima usando l'area amministrativa di PLESK, loggandomi sia come mywebsiteowner, poi come administrator del server, e non esserci riuscito, mi sono pure giocato la carta della connessione SSH al server, ma nemmeno qui è possibile effettuare l'escalation, per due motivi:
administrator non riesce a mettere il naso dentro la cartella httpdocs/, proprietà dell'utente mywebsiteowner
l'utente mywebsiteowner non riesce, nemmeno se loggato via SSH, a rimuovere gli stessi file che non riesce a rimuovere via FTP
Nemmeno l'escalation si riesce a fare diventando temporaneamente utente root, grazie a sudo root. Su questi server virtuali o dedicati Linux l'utente root è disabilitato e la strada per abilitarlo è un po' ostica, oltre che pericolosa.
In rete ho trovato una soluzione tanto semplice quanto geniale: è necessario fare in modo che l'utente apache elimini quei file o quantomeno ne cambi i previlegi in scrittura, mettendoli a 777 e mettendo qualche altro utente nelle condizioni di poterli cancellare. Ma come?
L'utente apache è proprio quello che sta interpreta gli script e le pagine php, per cui basterà scrivere una paginetta del menga in php!
La cosa pare funzionare, per cui la rimozione dei file può essere intrapresa anche da qualche altro utente, via File Manager all'interno di PLESK, via SSH o anche via FTP usando il client FTP di preferenza.
Non tutti sanno che Dropbox ha una funzionalità che consente di velocizzare enormemente la sincronizzazione dei file monitorati da Dropbox tra i computer che si trovano all'interno della stessa rete locale.
Questa impostazione è già attiva, per cui non dovete fare altro che beneficiarne.
La sincronizzazione LAN è una funzione di Dropbox che velocizza enormemente la sincronizzazione se il file si trova in una rete locale (LAN).
Che cosa significa esattamente? Se aggiungi un file al Dropbox del tuo computer, il file viene sincronizzato con i server Dropbox. Dropbox avvia poi il processo di sincronizzazione non appena determina che è stata apportata una modifica al file. Tutti i computer collegati e le cartelle condivise scaricheranno qualsiasi nuova versione del file. Con la sincronizzazione LAN, Dropbox andrà per prima cosa a cercare il nuovo file sulla rete locale, evitando così di dovere scaricare il file dai server Dropbox velocizzando incredibilmente il processo di sincronizzazione.
La sincronizzazione LAN è un vantaggio supplementare quando si usano PC in rete che condividono lo stesso router o all'interno di un altro tipo di rete locale.
A volte mi chiedo come sia possibile che Microsoft continui a superarsi nello stabilire record negativi. Da un colosso mondiale che, bene o male, ha ancora il controllo della maggioranza dei sistemi operativi desktop e degli applicativi per l'ufficio, ci si aspetterebbe di continuare a commettere gli stessi errori.
Magari invece sono io a sbagliarmi, perché l'errore in cui sono incappato non è attribuibile a Microsoft, però...
Mi capita di tanto in tanto di utilizzare l'applicazione Connessione Desktop Remoto su Lion (OS X 10.7.5). Mi connetto sostanzialmente dal Mac ad alcuni web server con Windows Server (2003 R2 o 2008) utilizzando l'applicazione RDC di Microsoft, un'applicazione gratuita.
All'uscita della sessione, che pare chiudersi correttamente server-side, pare che l'applicazione client di Microsoft si inchiodi e un'altra applicazione daemon monitora il crash allo scopo di inviare più o meno automaticamente alla Microsoft le informazioni diagnostiche.
Succede che anche il daemon si inchioda, stando a quanto compare nella finestra "Forza chiusura applicazioni" di Lion, cioè una versione leggera del Task Manager di Windows, messa a punto per abbattere proprio i processi che vanno in blocco.
Purtroppo il nome dell'applicazione tradotta in italiano è molto più lunga di quella originale in inglese e succede che la scritta in rosso viene accorciata in "Segnalazione errori Microsoft (non", ma ci sarebbe scritto "non risponde".
Molto bene: se un'applicazione principale si inchioda sporadicamente, può starci, ma che si inchiodi l'applicazione che segnala gli errori, vuol dire che non ci siamo proprio. Ad essere un po' sarcastici, ci vuole forse un'ulteriore applicazione per captare gli errori sollevati dall'applicazione che segnala gli errori, perché un'altra applicazione è andata in crash?
Ora io non dovrei mai permettermi di sputare nel piatto dove mangio, visto che io stesso utilizzo quotidianamente strumenti Microsoft per il lavoro e pure io sviluppo software proprio con gli strumenti Microsoft, cioè io "mangio" proprio utilizzando gli strumenti della casa di Redmond, però, come chiunque, auspicherei sempre un miglioramento continuo della stabilità dei software, sia degli applicativi che dei sistemi operativi.
Quanto sono diverse le vedute nello sviluppo del software!
Ho trovato tempo fa una vignetta su Itworld che ben descrive quello che succede nella realtà. Ogni parte in gioco ha un suo linguaggio ed una sua maniera di intendere le cose ed il risultato alla fine non è all'altezza delle aspettative, perché le colpe si riconoscono sempre nell'operato degli altri e non nel proprio.
La vignetta originale, disponibile da Project Cartoon, in realtà era in inglese, solo che io mi sono preso la briga di tradurla in italiano, in maniera leggermente diversa da come lo hanno fatto loro.
Reading
Fabio Volo - E' una vita che ti aspetto
Michael Guillen - Le 5 equazioni che hanno cambiato il mondo
Sophie Kinsella - I love shopping a New York
(p)Link
Commenti
Storico
Stampa
Feed RSS 0.91
Feed Atom 0.3