View Full Version : Ma come si programma ?
Thunderfox
19-01-2007, 19:38
Ciao a tutti, ho un problema che non riesco a risolvere, ovvero non riesco a capire come si fa a programmare...
Il problema è che ho provato ad iniziare con diversi linguaggi di programmazione, ma una volta letti i tutorial o le guide e una volta che ho imparato a stampare del testo sullo schermo (il classico hello world) e ad effettuare operazioni matematiche, ecc... , poi mi blocco...
Non riesco a capire cosa posso fare con tutto quello che ho imparato, visto che poi quando vado ad eseguire quello che ho scritto, mi ritrovo con una squallida finestra dos :rolleyes:
Per di più gli esempi che vengono proposti in quasi tutti i linguaggi di programmazione mi sembrano tutti privi di utilità.
Io vorrei programmare e avere come risultato dei veri e propri programmi che possono girare sotto windows (quindi con un minimo di grafica).
Come faccio ad applicare tutto quello che ho imparato, per creare programmi per windows ?
Premetto che ho acquistato un libro sul c++ ma alla fine gli esempi che vengono proposti, si basando sempre su programmi che si eseguono in finestre dos.
Help, di voglia di imparare ne ho tanta, ma sono in una fase di stallo.
Datemi qualche consiglio ;)
purtroppo per imparare a programmare la console è necessaria almeno all'inizio.
Se gia sai programmare abbastanza ti consiglio di utilizzare un ambiente RAD(Rapid application development) per programmare tipo delphi, con qualche guida gia puoi fare qualche programma piu divertente
buon lavoro :D
mapomapo
19-01-2007, 20:34
i linguaggi come il C o il C++ sono tutti testuali..ci vogliono le librerie visual per far quello che dici tu...
oppure puoi imparare a programmare in php...
Vito
se ti senti pronto buttati sul visual c++
http://www.microsoft.com/italy/msdn/prodotti/vs2005/editions/download/vc.mspx
il fatto è che a livelli un pò più seri è tutto codice e poca grafica. Nel senso che in quei "programmi per windows" di cui tu parli, la grafica rappresenta solo la rappresentazione dei dati, niente di più. Questo per dirti che prima stabilisci cosa fare, il come lo vuoi rappresentare è un problema secondario. Cmq sia puoi usare per esempio visual c++ che offre un modo molto facilitato di fare programmi visuali.
skintek1
19-01-2007, 21:41
io direi anche visual basic....cmq i veri programmi si scrivono.......
Quando serve i programmi bisogna anche disegnarli.
skintek1
20-01-2007, 01:36
non la penso cosi'....
alberto.frz
20-01-2007, 01:43
Io ti consiglio il di partire dal C. Le basi che impari ti faranno un bel bagaglio...poi prova tranquillamente linguaggi tipo visual c++ o visual basic cosi ti diverti anche un po' con la grafica.
L'unica cosa veramente importante è che bisogna :muro:
saluti (a tutti):Prrr:
Quando serve i programmi bisogna anche disegnarli.
esatto...oltre al design di un programma per quanto riguarda classi e strutture dati...c'è anche il design della gui...e un visual studio che integra un editor bell'e pronto benvenga.
giannola
20-01-2007, 12:58
Ciao a tutti, ho un problema che non riesco a risolvere, ovvero non riesco a capire come si fa a programmare...
Il problema è che ho provato ad iniziare con diversi linguaggi di programmazione, ma una volta letti i tutorial o le guide e una volta che ho imparato a stampare del testo sullo schermo (il classico hello world) e ad effettuare operazioni matematiche, ecc... , poi mi blocco...
Non riesco a capire cosa posso fare con tutto quello che ho imparato, visto che poi quando vado ad eseguire quello che ho scritto, mi ritrovo con una squallida finestra dos :rolleyes:
Per di più gli esempi che vengono proposti in quasi tutti i linguaggi di programmazione mi sembrano tutti privi di utilità.
Io vorrei programmare e avere come risultato dei veri e propri programmi che possono girare sotto windows (quindi con un minimo di grafica).
Come faccio ad applicare tutto quello che ho imparato, per creare programmi per windows ?
Premetto che ho acquistato un libro sul c++ ma alla fine gli esempi che vengono proposti, si basando sempre su programmi che si eseguono in finestre dos.
Help, di voglia di imparare ne ho tanta, ma sono in una fase di stallo.
Datemi qualche consiglio ;)
tu soffri della classica sindrome di "mancanza di obiettivo", ovvero assimili le regole di programmazione ma poi non sai come metterle insieme semplicemente perchè non ti sei posto un obiettivo, ovvero un programma da realizzare.
Saper programmare non è tutto bisogna anche sapere fare una analisi di ciò che si vuole realizzare e come implementarlo.
Supponi ad esempio di volere fare una rubrica telefonica dunque devi innanzitutto raccogliere dei dati e memorizzarli, poi dovrai anche visualizzarli magari attraverso una ricerca.
In genere si parte da una idea e poi ci si domanda come svilupparla, una volta che si ha uno schema allora si può iniziare a programmare.
Finchè non ti sarai dato un obiettivo (comincia da qualcosa di semplice) non imparerai mai a programmare. ;)
giannola
20-01-2007, 13:03
il fatto è che a livelli un pò più seri è tutto codice e poca grafica. Nel senso che in quei "programmi per windows" di cui tu parli, la grafica rappresenta solo la rappresentazione dei dati, niente di più. Questo per dirti che prima stabilisci cosa fare, il come lo vuoi rappresentare è un problema secondario. Cmq sia puoi usare per esempio visual c++ che offre un modo molto facilitato di fare programmi visuali.
questo è un approccio infondato.
Se ci si basa sulla programmazione ad oggetti l'orientamento grafico per rappresentare gli stessi è il passo necessario per programmare efficentemente.
Gli oggetti non sono materia inerte da programmare ma sono entità con attributi e metodi propri i quali al limite possono essere ulteriormente implementati e non necessariamente sono contenitori di dati ma realizzano funzioni complesse.
Se si dovesse scrivere tutto il codice necessario per non usare gli oggetti a disposizione in pratica si finirebbe molto, ma molto più tardi.
questo è un approccio infondato.
Se ci si basa sulla programmazione ad oggetti l'orientamento grafico per rappresentare gli stessi è il passo necessario per programmare efficentemente.
Gli oggetti non sono materia inerte da programmare ma sono entità con attributi e metodi propri i quali al limite possono essere ulteriormente implementati e non necessariamente sono contenitori di dati ma realizzano funzioni complesse.
Se si dovesse scrivere tutto il codice necessario per non usare gli oggetti a disposizione in pratica si finirebbe molto, ma molto più tardi.
Non ho capito che c'entra con quello che stavo dicendo io. Io non ho parlato di programmazione oggetti. Intendevo dire che devi prima porti un obiettivo, progettarlo (ad oggetti o come ti pare) e poi di preoccuparti della parte visuale. Se non sai cosa fa il tuo programma è inutile che progetti le i bottoni e le finestre, per farla breve.
Io vorrei programmare e avere come risultato dei veri e propri programmi che possono girare sotto windows (quindi con un minimo di grafica). se vuoi imparare a programmare specificamente per Windows esiste la libreria MSDN, ovvero la documentazione ufficiale di Microsoft sulla programmazione Windows. MSDN contiene tutto lo scibile (ovvero tutto ciò che ci è dato sapere) su Windows. questo è l'URL dell'indice principale in MSDN sulla programmazione Win32 (la sezione però in realtà include anche il DDK, che serve a programmare drivers per Windows): http://msdn2.microsoft.com/en-us/library/aa139672.aspx
per consultare MSDN ovviamente è richiesta una buona conoscenza di C e C++. inoltre per quando programmi su Windows ti consiglio di utilizzare Microsoft Visual Studio 2005 in edizione Express, oppure Enterprise se sei uno studente universitario e alla tua università hanno MSDNAA.
se proverai a fare qualche esperimento di applicazione grafica in Windows utilizzando le funzioni Win32 ti accorgerai molto presto che utilizzare direttamente Win32 è un lavoro molto oneroso per un programmatore, e siccome per un programmatore "lavoro oneroso" significa "lavoro error-prone" ti chiederai se non esistano set di funzioni/classi per C/C++ già pronti che ti semplifichino le cose permettendoti ad esempio ti assolvere compiti molto comuni senza dover riscrivere ogni volta una dozzina di chiamate Win32 con relativi controlli sul codice di errore ritornato. la risposta è si :) tali set si chiamano "frameworks" ed uno che io trovo assolutamente ottimo è wxWidgets (www.wxwidgets.org).
giannola
20-01-2007, 15:43
Non ho capito che c'entra con quello che stavo dicendo io. Io non ho parlato di programmazione oggetti. Intendevo dire che devi prima porti un obiettivo, progettarlo (ad oggetti o come ti pare) e poi di preoccuparti della parte visuale. Se non sai cosa fa il tuo programma è inutile che progetti le i bottoni e le finestre, per farla breve.
allora ho capito male, adesso somiglia tanto al mio primo post :D
Thunderfox
20-01-2007, 20:36
tu soffri della classica sindrome di "mancanza di obiettivo", ovvero assimili le regole di programmazione ma poi non sai come metterle insieme semplicemente perchè non ti sei posto un obiettivo, ovvero un programma da realizzare.
Saper programmare non è tutto bisogna anche sapere fare una analisi di ciò che si vuole realizzare e come implementarlo.
Supponi ad esempio di volere fare una rubrica telefonica dunque devi innanzitutto raccogliere dei dati e memorizzarli, poi dovrai anche visualizzarli magari attraverso una ricerca.
In genere si parte da una idea e poi ci si domanda come svilupparla, una volta che si ha uno schema allora si può iniziare a programmare.
Finchè non ti sarai dato un obiettivo (comincia da qualcosa di semplice) non imparerai mai a programmare. ;)
Bravo hai centrato in pieno il mio problema.
Sia in c++ che in python avevo provato a fare una rubrica, con tanto di menù per aggiungere voci, cancellarle, ecc...
Però l'esecuzione avveniva sempre tramite console di windows.
Avrei voluto fare la stessa cosa ma in una finestra di windows, purtroppo non so come legare il codice alla grafica. :(
Cmq grazie delle risposte e dei consigli, avete risposto veramente in tanti :eek:
Forse prenderò in considerazione il visual c++.
Forse prenderò in considerazione il visual c++. bravo :P
e scarica la versione 2005 :P
jappilas
21-01-2007, 15:28
<....>
Avrei voluto fare la stessa cosa ma in una finestra di windows, purtroppo non so come legare il codice alla grafica. :(
<....>
oh, bene - cioè, abbiano trovato il primo "obiettivo" :)
a questo punto, come prima cosa direi che dovresti cercare di "visualizzare" l' aspetto che dovrebbe avere la tua applicazione (magari con uno schizzo su carta): questo per identificare quali widget o "controlli" (liste, campi di testo, griglie, finestre grafiche eccetera... ) saranno necessari nel tuo programma, e farti un' idea del "flusso" operativo che l' interfaccia esporrà: ora per una rubrica questo passaggio sarà abbastanza semplice ...
una volta determinata la struttura della parte visiva della tua applicazione, è da valutare quale toolkit library usare per implementarla - tenendo conto che ognuna ha una propria API, proprie particolarità e idiosincrasie , e quindi modalità d' uso differenti ...
scelto un toolkit, è da acquisire la sua API, quantomeno per ciò che concerne il o i widget di cui hai bisogno, e le problematiche e necessità di quel toolkit a livello generale ( ad es, routine di inizializzazione comuni a tutta la libreria, modello d' uso, convenzioni eccetera ): quindi , anche se pensavi di saper programmare, dovrai rimetterti a studiare perchè un conto è il linguaggio, un conto sono le funzioni di libreria ...
Inoltre tieni conto che i "widget", quelli integrati in una libreria (come può essere MFC, GTK, QT), come quelli che magari svilupperai tu o magari comprerai (come ho scoperto leggendo msdn magazine, decine di società campano vendendo "controlli" aggiuntivi e activeX, alcuni davvero belli e sofisticati :D) per sopperire alle necessità di una tua applicazione - spesso e volentieri NON operano direttamente sui dati del l working set dell' applicazione, ma su un subset costruito per la presentazione e l' interazione
Anche se può apparire banale, questo dovrebbe farti intuire che nel tuo programma andranno implementate in modo appropriato le chiamate per l' inizializzazione dei widget presenti, quelle per l' aggiornamento (modifica della struttura dati in memoria -> aggiornamento del contenuto della finestra, caso banale pressione di "CANC" in una lista con un elemento selezionato) e i punti in cui il tuo codice reagisce a condizioni notificate DAL widget o come le notifica AL widget : in pratica "legare il codice alla grafica" è l' ultimo passo...
è vero che in un ambiente RAD con i wizard per creare nuovi metodi nella tua classe, o nuovi progetti basati su template tra cui magari applicazioni centrate su quella certa GUI library, o per abbinare un certo messaggio a un metodo ... questo è molto semplificato
ma comunque presuppone la conoscenza del significato di un certo messaggio notificato, o della funzione di una certa callback o... , a questo serviva il passaggio precedente (studio della API e delle particolarità della libreria , conoscenza che comunque acquisirai una tantum per una determinata combinazione "OS /famiglia di OS" - toolkit e spesso potrai riutilizzare )
E comunque tieni conto che anche i wizard inseriscono sezioni di codice nei file del tuo progetto, quindi in effetti come diceva qualcuno, "è sempre codice" ...
mindwings
21-01-2007, 17:58
oh, bene - cioè, abbiano trovato il primo "obiettivo" :)
a questo punto, come prima cosa direi che dovresti cercare di "visualizzare" l' aspetto che dovrebbe avere la tua applicazione (magari con uno schizzo su carta): questo per identificare quali widget o "controlli" (liste, campi di testo, griglie, finestre grafiche eccetera... ) saranno necessari nel tuo programma, e farti un' idea del "flusso" operativo che l' interfaccia esporrà: ora per una rubrica questo passaggio sarà abbastanza semplice ...
una volta determinata la struttura della parte visiva della tua applicazione, è da valutare quale toolkit library usare per implementarla - tenendo conto che ognuna ha una propria API, proprie particolarità e idiosincrasie , e quindi modalità d' uso differenti ...
scelto un toolkit, è da acquisire la sua API, quantomeno per ciò che concerne il o i widget di cui hai bisogno, e le problematiche e necessità di quel toolkit a livello generale ( ad es, routine di inizializzazione comuni a tutta la libreria, modello d' uso, convenzioni eccetera ): quindi , anche se pensavi di saper programmare, dovrai rimetterti a studiare perchè un conto è il linguaggio, un conto sono le funzioni di libreria ...
Inoltre tieni conto che i "widget", quelli integrati in una libreria (come può essere MFC, GTK, QT), come quelli che magari svilupperai tu o magari comprerai (come ho scoperto leggendo msdn magazine, decine di società campano vendendo "controlli" aggiuntivi e activeX :D) per sopperire alle necessità di una tua applicazione - spesso e volentieri NON operano direttamente sui dati del l working set dell' applicazione, ma su un subset costruito per la presentazione e l' interazione
Anche se può apparire banale, questo dovrebbe farti intuire che nel tuo programma andranno implementate in modo appropriato le chiamate per l' inizializzazione dei widget presenti, quelle per l' aggiornamento (modifica della struttura dati in memoria -> aggiornamento del contenuto della finestra, caso banale pressione di "CANC" in una lista con un elemento selezionato) e i punti in cui il tuo codice reagisce a condizioni notificate DAL widget o come le notifica AL widget : in pratica "legare il codice alla grafica" è l' ultimo passo...
è vero che in un ambiente RAD con i wizard per creare nuovi metodi nella tua classe, o nuovi progetti basati su template tra cui magari applicazioni centrate su quella certa GUI library, o per abbinare un certo messaggio a un metodo ... questo è molto semplificato
ma comunque presuppone la conoscenza del significato di un certo messaggio notificato, o della funzione di una certa callback o... , a questo serviva il passaggio precedente (studio della API e delle particolarità della libreria , conoscenza che comunque acquisirai una tantum per una determinata combinazione "OS /famiglia di OS" - toolkit e spesso potrai riutilizzare )
E comunque tieni conto che anche i wizard inseriscono sezioni di codice nei file del tuo progetto, quindi in effetti come diceva qualcuno, "è sempre codice" ...
dopo questo intervento non credo che abbia idee chiare come prima :D
secondo me dovresti imparare a programmare per il web :)
quello che cerchi è la concretezza e sviluppare un programma
ti potrebbe portare via molto tempo prima di vedere dei risultati
accettabili. mentre vedere anche del codice html scritto in maniera corretta
può dare più soddisfazione e voglia di continuare a programmare / imparare :fagiano:
dopo questo intervento non credo che abbia idee chiare come prima :D
secondo me dovresti imparare a programmare per il web :)
quello che cerchi è la concretezza e sviluppare un programma
ti potrebbe portare via molto tempo prima di vedere dei risultati
accettabili. mentre vedere anche del codice html scritto in maniera corretta
può dare più soddisfazione e voglia di continuare a programmare / imparare :fagiano: allora forse gli volevi consigliare di programmare in Java o in .NET, non in HTML :p
yorkeiser
22-01-2007, 12:19
La programmazione ha poco a che vedere con la rappresentazione grafica dei dati. Non mi sembra ci sia troppa differenza dallo sparare i dati su console o su una finestra di winzozz, piuttosto che su una stampante o un computer remoto; piuttosto ciò che fa la differenza è come progetti le applicazioni ed un minimo di padronanza degli algoritmi basilari. Poi ci sono tanti ragazzi che per arrotondare la paghetta fanno finestrelle in VB, ma mi sembri molto lontano dal concetto di programmazione.
mindwings
22-01-2007, 14:11
allora forse gli volevi consigliare di programmare in Java o in .NET, non in HTML :p
:D è talmente dispersivo il mondo dell'informatica che puoi fare tutto o niente
quello dell'html era un esempio banale :fagiano:
Se programmare significa rappresentare la soluzione ad un problema attraverso un calcolatore allora una GUI è una soluzione che appartiene ad una classe di problemi diversa da altre. Poichè la soluzione precede la rappresentazione non sussiste alcuna differenza tra scrivere GUI e scrivere altro.
Il fatto che ci sia un prius nella programmazione, cioè la soluzione del problema, evidenzia la possibilità che problemi diversi possano finire in rappresentazioni strutturalmente simili. Un decorator o un listener possono darsi tanto in una GUI quanto in un HAL.
La presenza di un identico mezzo, il calcolatore, ci dice che non solo normale, ma necessario che, citando il citante, sia "...sempre codice".
Non posso escludere che occuparsi di GUI significhi arrotondare la paghetta. Mi piacerebbe tuttavia sapere quale sia la definizione di programmazione che produce questa deminutio.
^TiGeRShArK^
22-01-2007, 15:52
allora forse gli volevi consigliare di programmare in Java o in .NET, non in HTML :p
ma soprattutto...
da quando in qua l'html è un linguaggio di programmazione ?:mbe:
giannola
22-01-2007, 16:11
ma soprattutto...
da quando in qua l'html è un linguaggio di programmazione ?:mbe:
se è dhtml allora lo diventa :Prrr: :D
yorkeiser
22-01-2007, 16:26
Se programmare significa rappresentare la soluzione ad un problema attraverso un calcolatore allora una GUI è una soluzione che appartiene ad una classe di problemi diversa da altre. Poichè la soluzione precede la rappresentazione non sussiste alcuna differenza tra scrivere GUI e scrivere altro.
Il fatto che ci sia un prius nella programmazione, cioè la soluzione del problema, evidenzia la possibilità che problemi diversi possano finire in rappresentazioni strutturalmente simili. Un decorator o un listener possono darsi tanto in una GUI quanto in un HAL.
La presenza di un identico mezzo, il calcolatore, ci dice che non solo normale, ma necessario che, citando il citante, sia "...sempre codice".
Non posso escludere che occuparsi di GUI significhi arrotondare la paghetta. Mi piacerebbe tuttavia sapere quale sia la definizione di programmazione che produce questa deminutio.
Scrivere GUI è un piccolissimo aspetto di un mondo MOLTO vasto come quello della programmazione, questo era il senso del mio intervento. Leggendo alcuni post mi sembra che qualcuno parteggi per l'equazione programmazione = figa se c'è la GUI, merda se c'è la console. Beh, il windows e in genere gli o.s. user-friendly (definizione molto discutibile, bisognerebbe specificare per quale tipo di user) è piuttosto recente, il calcolatore piuttosto anzianotto; pare che i sistemi girassero (e a volte anche bene, che ci si creda o meno) anche prima dell'avvento delle GUI. Ed a questo aggiungo una mia piccola considerazione personale, ovviamente discutibile in quanto soggettiva: buttare giù due frame, qualche bottone e attaccarci un listener mi sembra uno dei lati più pallosi di questo universo... ripeto, considerazione semplicemente soggettiva e che nasce dalla mia esperienza personale
mindwings
22-01-2007, 16:35
se dico python php ruby va meglio??:D se dico agile development (ruby/python):)
Supponendo che per chiunque si intenda un essere umano allora le applicazioni la cui GUI sia una console, cioè qualcosa che accetta comandi espressi in forma di testo, attraverso una tastiera, sono, dal punto di vista dell'usabilità, le peggiori che si possano creare.
Probabilmente chi scrive applicazioni che usino la console come GUI lo fa per il vantaggio immediato offerto dalla stringa di testo come comando. Dal punto di vista del programmatore, il comando testuale è facilmente intercettabile e gestibile. Chi non ha voglia di risolvere il problema dell'interazione si appoggia ad una soluzione già disponibile.
Ma è sufficiente mettersi nei panni di quel chiunque per rendersi conto dell'abisso tra la digitazione e la selezione, tra il testo e l'immagine, tra la tastiera e il touch-screen.
La programmazione ha poco a che vedere con la rappresentazione grafica dei dati. Non mi sembra ci sia troppa differenza dallo sparare i dati su console o su una finestra di winzozz, piuttosto che su una stampante o un computer remoto; piuttosto ciò che fa la differenza è come progetti le applicazioni ed un minimo di padronanza degli algoritmi basilari. questo è quello che ti insegnano talvolta all'università, o anche solo al professionale. ed è sbagliato (oltre a non avere molto senso).
Poi ci sono tanti ragazzi che per arrotondare la paghetta fanno finestrelle in VB, ma mi sembri molto lontano dal concetto di programmazione. Visual Basic permette di essere molto produttivi nel progettare interfacce grafiche; per il resto il discorso varia molto a seconda della versione di cui parliamo. la 6 è una merda, senza troppi mezzi termini: stravolge concetti basilari di OOP confondendo i concetti di classe e oggetto, ed inoltre è nativamente poco potente (è sostanzialmente uno strumento di scripting per gestione degli ActiveX: se ha della potenza lo deve a quelli).
la .NET invece... potrebbe essere molto diversa; non lo so perché non l'ho mai provata. ma non credo abbia molto senso usarla quando esiste Visual C#.
yorkeiser
24-01-2007, 16:33
questo è quello che ti insegnano talvolta all'università, o anche solo al professionale. ed è sbagliato (oltre a non avere molto senso).
All'università mi insegnavano matematica ed elettronica più che altro. E' quello che ho appreso in qualche annetto di esperienza lavorativa prima, durante e dopo l'università
Visual Basic permette di essere molto produttivi nel progettare interfacce grafiche; per il resto il discorso varia molto a seconda della versione di cui parliamo. la 6 è una merda, senza troppi mezzi termini: stravolge concetti basilari di OOP confondendo i concetti di classe e oggetto, ed inoltre è nativamente poco potente (è sostanzialmente uno strumento di scripting per gestione degli ActiveX: se ha della potenza lo deve a quelli).
Ho sempre adorato la snellezza sintattica del Basic (primo linguaggio che imparai tra l'altro, era l'86 e la Francia ci eliminava mestamente dai mondiali del Messico), ma il visual te lo lascio volentieri: lento, bacato e insulso a livello di architettura, indipendentemente dalla versione.
la .NET invece... potrebbe essere molto diversa; non lo so perché non l'ho mai provata. ma non credo abbia molto senso usarla quando esiste Visual C#.
Non conosco VC#, ho lavorato solo su VS.NET (WC NET): prima di dire che sia inutile magari chiedi a qualcuno che abbia esperienza su entrambe; personalmente non mi pongo neanche il problema e resto molto volentieri sul Java. Punti di vista, naturalmente. Comunque, mi sembra che a qualcuno manchi un concetto di base: l'informatica è nata molto prima che Microsoft provasse a soggiogarla (e non parteggio per linux o macOS o quel che l'è; dal mio punto di vista, un'applicazione dovrebbe essere SEMPRE indipendente dal s.o. su cui gira e con la robaccia Microcozz non è MAI così). Il marketing è una cosa, l'informatica un'altra.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.