Ogni nostro incarico parte dalla stessa domanda: dove volete arrivare, e cosa vi sta bloccando? La maggior parte dei nostri clienti ha scadenze reali, vincoli reali e un’operatività che non può fermarsi mentre il software viene sostituito. Per questo il lavoro è costruito attorno al risultato che cercate, non attorno alle ore fatturabili.
Tre modi per coinvolgerci. La maggior parte dei clienti parte da uno e poi passa a un altro.
Leadership tecnica senior senza un’assunzione a tempo pieno, per i team che hanno bisogno di una direzione, non solo di esecuzione.
Ingegneri senior che si inseriscono e producono dal primo giorno, e lasciano il vostro team più forte di come l’hanno trovato.
Analisi di business e discovery che trasformano un concetto abbozzato in un piano definito, stimato e realizzabile.
Workshop privati su architettura, sprint planning e stime, discovery e roadmap, standard di ingegneria, .NET MAUI e migrazione da Xamarin, Bluetooth LE ed esecuzione in background, .NET moderno e AI. Costruiti sul vostro codice e tenuti dalle persone che hanno scritto le librerie presenti nel vostro file di progetto.
La maggior parte dei progetti di AI si arena molto prima che il problema sia il modello. I dati che servono stanno su un dispositivo, dentro un sistema legacy o in un formato che nulla può interrogare. Noi lavoriamo sull’intero percorso: dal punto in cui i dati nascono a quello in cui un assistente può usarli in sicurezza.
La metà poco appariscente: portare i vostri dati dal punto in cui nascono a un luogo in cui un modello può raggiungerli, senza perderne per strada.
Esporre i vostri sistemi a un assistente in modo intenzionale, non con il copia-incolla, con confini chiari su cosa può vedere e fare.
Assistenti, voce e automazione integrati nell’app che i vostri utenti hanno già aperta, invece dell’ennesima scheda da ricordare.
Raramente il punto debole è la tecnologia. È un rollout che nessuno ha misurato, dati finiti dove non dovevano, o un processo affidato in silenzio a un modello di cui nessuno risponde. Queste sono le regole che rispettiamo in ogni incarico di AI.
Un solo processo, con un costo che si può davvero misurare, dimostrato prima di estendere qualsiasi cosa. I rollout aziendali a sensazione sono il modo in cui i budget per l’AI vengono cancellati.
Cosa esce dalla vostra rete, su cosa un fornitore può addestrare i suoi modelli e dove possono risiedere i dati regolamentati: deciso consapevolmente e messo per iscritto prima del primo prompt.
Tutto ciò che tocca denaro, sicurezza o un cliente resta soggetto all’approvazione di una persona, e il sistema registra chi ha deciso cosa. L’AI prepara la bozza; il vostro team firma.
Valutato su casi reali della vostra azienda, così conoscete l’accuratezza prima che la scoprano i vostri clienti, e potete accorgervi quando il modello inizia a deviare.
Il modello è un componente sostituibile. I vostri dati, i vostri strumenti e le vostre valutazioni sono il vero patrimonio, e restano portabili la prossima volta che questo mercato cambia.
Alcuni processi non vanno automatizzati, e alcuni problemi costano meno se risolti con una schermata migliore. Ve lo diremo prima che abbiate pagato l’alternativa.
Una breve analisi di quali dati avete già, quali state buttando via e di cosa avrebbe davvero bisogno un modello per rispondere alle domande che contano per la vostra azienda. Di norma richiede un paio di settimane e produce un piano di cui potete stimare i costi, spesso con la scoperta utile che la prima fase è infrastruttura, non AI.
Un elenco breve, di proposito. Sono gli ambiti in cui siamo davvero tra le persone che vorreste sul problema: mobile, dispositivi connessi e i servizi cloud che li tengono insieme.
App .NET MAUI, iOS e Android in produzione e conversioni da Xamarin a MAUI, compreso il lavoro su background, offline e ciclo di vita che la maggior parte dei team sbaglia. Collaboriamo con il team .NET MAUI di Microsoft fin dalla nascita di MAUI.
BLE central e peripheral, flotte di dispositivi e integrazione hardware. Le librerie che il settore usa per questo le abbiamo scritte noi.
Tracciamento della posizione, geofencing e telematica per veicoli e squadre che lavorano dove la connettività non è garantita.
App per Apple Watch, Wear OS, CarPlay e Android Auto che portano la vostra app mobile al polso e sul cruscotto, pensate per uno sguardo o un comando vocale, non per lo schermo di un telefono in miniatura. Il collegamento tra telefono e orologio si basa su una libreria che abbiamo scritto noi.
I servizi e le API ASP.NET Core dietro il dispositivo: pensati per un deploy pulito, costi operativi contenuti e tenuta quando l’intera flotta trasmette dati nello stesso momento.
Portare codebase .NET Framework legacy e app mobile datate su piattaforme attuali senza fermare lo sviluppo.
Venticinque anni in realtà operative dove il software deve reggere l’impatto con il mondo reale: camion, magazzini, cantieri, corsie d’ospedale e code di chiamate.
Le conversioni da Xamarin a .NET MAUI sono una nostra specialità, e lo è anche .NET MAUI stesso. Collaboriamo con il team .NET MAUI di Microsoft fin dalla nascita di MAUI, e le nostre librerie hanno contribuito a plasmare l’ecosistema su cui oggi si costruiscono le app MAUI.
Il supporto a Xamarin è terminato a maggio 2024. Quello che blocca questi porting non è quasi mai la conversione della UI: è l’elenco delle dipendenze. Ogni plugin abbandonato dietro Bluetooth, attività in background, posizione, notifiche push, archiviazione e sincronizzazione va sostituito con qualcosa che nessuno nel team ha mai usato in produzione. È in quella valutazione che se ne vanno i mesi, ed è lì che sta il rischio.
Non c’è una sezione di un’app mobile per cui vi restituiamo un elenco di opzioni da andare a studiare. Prendete qualsiasi parte della vecchia app: la risposta esiste già.
Un’analisi delle dipendenze e dei rischi sulla soluzione esistente: cosa si trasferisce direttamente, cosa non ha equivalenti e cosa non dovrebbe sopravvivere affatto al passaggio. Il risultato è un piano a fasi di cui potete stimare i costi, e il porting procede piattaforma per piattaforma accanto alla vostra roadmap, senza congelarla.
Non tutti gli incarichi MAUI sono migrazioni. Aiutiamo anche i team che il passaggio lo hanno già fatto: prestazioni e tempi di avvio, lavoro in background che ha smesso di partire dopo un aggiornamento del sistema operativo, handler e codice di piattaforma, crash che si riproducono solo su dispositivi reali, e stare al passo con ogni nuova release di .NET. Coinvolgeteci per una revisione, per un problema ostinato o come ingegneri MAUI senior accanto ai vostri.
Il .NET legacy non è un unico problema. Un’app WebForms, uno strato di servizi WCF e un client WinForms si bloccano per motivi completamente diversi, e una stima vale quanto l’esperienza di chi in quello stack ci ha vissuto davvero. Abbiamo scritto codice di produzione in tutti, compresi quelli in VB.NET che nessuno vuole aprire, quindi la valutazione attinge alla memoria invece che a una fase di ricerca pagata da voi.
Il ciclo di vita della pagina, il ViewState e i server control non hanno equivalenti, quindi il markup va davvero riscritto. La logica di business sottostante di solito no, e separare le due cose è gran parte del lavoro.
Binding, behavior e contratti SOAP non si portano. Dove i chiamanti sono terze parti che non potete cambiare, CoreWCF mantiene in vita il contratto mentre tutto ciò che c’è dietro si sposta.
Non c’è niente verso cui migrare: il runtime è sparito da tutti i browser. Questi progetti iniziano con una conversazione di scoping su ciò che l’applicazione doveva davvero fare.
Il livello dati è dove un porting lineare diventa costoso. Traduzione delle query, transazioni e lazy loading si comportano tutti in modo diverso, e le differenze emergono in produzione, non in compilazione.
La cosa più vicina a un porting meccanico in questo elenco. Il vero lavoro sono hosting, configurazione, dependency injection e pipeline dei middleware, non i vostri controller.
Entrambi girano ancora sul .NET moderno, quindi raramente si tratta di una riscrittura. A bloccarla sono le suite di controlli di terze parti abbandonate e l’interop COM, che è la prima cosa che andiamo a cercare.
Le librerie condivise sono ciò che permette al vecchio e al nuovo sistema di funzionare fianco a fianco. Portarle prima in multi-targeting è di solito la chiave che sblocca tutto il resto di questo elenco.
Poco appariscente, ed è ciò che rende ripetibile tutto il resto. Ripaga anche molto prima che la migrazione finisca, ed è per questo che spesso è la cosa giusta da fare per prima.
Niente di questo elenco viene sostituito in un unico rilascio. Lo schema che funziona è lo strangler: si mette in piedi il nuovo stack accanto al vecchio, si sposta una porzione alla volta dietro gli stessi URL e si tengono attivi entrambi finché dal lato vecchio non resta più nulla. Sulla carta sembra più lento, ed è l’unica versione che abbiamo visto arrivare in fondo.
Diteci cosa state cercando di costruire. Vi diremo onestamente se siamo la scelta giusta, e cosa faremmo per prima cosa.
Usiamo Google Analytics per capire su quali pagine vale la pena scrivere di più. Resta disattivato finché non ci direte il contrario, e nulla su questo sito dipende da esso. Consultate la nostra informativa sulla privacy.
