| The Ultimate Business Machine Technology, business And, not least, about by: Bernard Teo
|
Tue 10 Oct 2006 Luca in FrenchCategory : Technology/Luca2dot3dot1.txt I've updated Luca to 2.3.1 to include a new French localisation by Joselyne Rochaud and Corentin Cras-Méneur.
Thanks, as always, Josy and Corentin. Mon 09 Oct 2006 Late for the SkyCategory : Commentary/LateForTheSky.txt I thought I was going to do my usual evening jog but the haze from the on-going forest fires in Indonesia looked rather bleak and menacing, and so I veered left into the "jungle" to get some respite. I live next to this huge body of water, the MacRitchie Reservoir, and its luxuriant canopy of raintrees acts as a sort of filter, providing somewhat more breathable air for me and my fellow-joggers. And I was thinking about those Jackson Browne songs : "Some of them were angry "Keep a fire burning in your eye
I ran and ran, in defiance of the haze, and was somewhat surprised, when I reached the end of the trail, to have done 10 km. But with that fog, the sky will be dark way before sunset, and who knows what darkness brings in the jungle, and so I doubled back, double-quick. That made it 20 km today and I hardly ever do 4 km, let alone 10. Whenever I'm wracked by tiredness and wished to stop, I only have to think, "if I stop, my company will die" and that superstition will be enough to push me on again. Morbid? But I've kept going for more than 12 years now. One does need will-power whenever belief goes AWOL. (And I guess that's the Loneliness of the Long Distance Runner as a metaphor for life...) So, talking about loneliness and fear, belief and self-doubt, this is the music of my lost youth - Jackson Browne and Late For The Sky. It's amazing that this is 30 years old now, but listen to "Fountain of Sorrow" again - it could have formed the perfect music accompaniment to an Apple iPhoto advert. Funny how past and present collide. And all triggered by a run in the fog.
"Looking through some photographs I found inside a drawer If there's a technology or an opportunity that can transport me back to any one day in my life, I would take it. Sat 07 Oct 2006 Make Work. And Real Work.Category : Commentary/MakeWorkRealWork.txt In Cocoa, if you want to know when the contents of a text field has changed, you assign the job of listening to changes being made to the field to the object that is managing your window (the window controller). This is called "making the Window Controller the Delegate of the Text Field". And this is how you do it - by linking the text field to the controller using Interface Builder:
This works OK in a beginner's class, but in a real application with many windows and many fields, it becomes a pain to link each field one at a time. What if you forget? It gets ugly with all these connections cropping up all over the place. It's complicated, cluttered and laboured - a sure sign that there ought to be a better way. I wanted to see if I can avoid doing all these linking in Interface Builder and still be able to tell when data has changed sufficiently that it needs to be saved. And from preferably just one place in the code. I spent days figuring out if that's possible. I tried everything. I sub-classed NSTextField, NSControl, NSText. I wrote my own categories. I traced the calls up and down the class hierarchy. I just refused to make those links in Interface Builder. In part, it's because I'm lazy. Part of it is because it's really too messy if you want to build things fast and yet want things to be precisely under control. And part of it is because I have faith in Cocoa's designers. It can't be that stupid. I went round in circles but I couldn't give up. Especially in an application like Luca, I needed a mechanism to tell precisely when it's the right time to enable the Save button, if I want to protect the user from saving inconsistent data and upsetting the balance of the accounts. And I need this mechanism to be simple, small, elegant, and easily implemented. I plan to build other business applications after Luca. If I can find a better way, I'll be able to build all these other applications faster. Then one day, I saw it. Just one line of code. And I'm off. Now, Cocoa is just like that - one line of code here, and another line of code there, and you get significant amount of work done. That's its beauty. But the reason I'm bringing this up is to highlight something else, using this experience as an example. And that is, how can you tell make-work from real-work, if you're overseeing software development? How do you tell when someone is working, when days go without measurable progress? And this is a double-edged sword. How can you tell that some programmer is not actually working, when he does in fact produce measurable lines of code? I can give you one example. Say, a programmer has to write a Unix batch job to process many thousands of records. It takes hours to process those records. So he writes his code, hits Run, and he stares at the screen and his mind is elsewhere for the next three hours, after which he finds bugs in his code, makes changes, hits Run, and in another two iterations, it's time for him to go home. If you're smart, you'll ask him why he can't just test his logic against a representative sample of records that gets run in a mere few seconds. And when he's done getting the logic right, do a test run against the whole thousands of records to see if the solution scales OK. That'll get the job done in a day, and let him know you know. And keep him on his toes forever more. But is it possible to understand and thereby manage the software development process (and make decisions on what platforms to standardise on, what directions to take, technologies to adopt, etc.), if you're not yourself a competent programmer? I'll leave this question hanging for today. It's the weekend after all. :-) Fri 06 Oct 2006 Luca 2.3 RelesedCategory : Technology/Luca2dot3.txt I've released Luca 2.3 to run on OS X 10.4.8. All the Preference Settings and Utility windows are now consolidated into one single Luca Preferences window, below : (leaving Luca with just two menus - one for Accounts and the other for Journal)
Currency display formats and decimal number precision can now be set for individual currencies (e.g., the Japanese yen has no decimal places and you can now set this, as shown below, by setting Max fraction digits to 0) :
Instead of having its own Utility window, you can now check the status of the accounting period (e.g., whether you had closed the accounts for a certain month) in the Periods pane in the Preferences :
Certain accounts play important roles in the accounting system, e.g., you need to have an account to post Foreign Exchange Gain/Loss amounts to, and you need an account to post the year's Retained Earnings to, and you need to set up Checking Accounts that are linked to your bank accounts. This is now made clearer in the following Preference pane, which you can also use to assign a different account to play the selected role instead (if you had not yet made any postings to that special account) :
Finally, some changes have been made to Luca's database structure. You can use the following Preference Pane to upgrade an older Luca database :
To update an older MySQL database, re-import it into LucaDB (the built-in SQLite database), using the second button shown above. And then Export it back into MySQL. That should effect the database change. The third button, shown above, is to allow the user to re-use an older SQLite-based Luca database. Just click on the button and show Luca where that previous SQLite LucaDB database is stored. Of course, the whole point of this 2.3 release is to take advantage of Cocoa's NSDecimalNumber class to improve the numeric accuracy of Luca's data handling, and MySQL's ability to store these data objects as an equivalent Decimal data type. With this release I've eliminated the rounding errors associated with the use of floating point numbers, though some of this remains if we use the SQLite database since SQLite does not yet support the Decimal number format. But at least we've made some significant progress in business computing. And on the Mac, no less. I have been holding on to a French localisation of Luca, contributed by Corentin Cras-Méneur, for almost two months already, while I was working on these changes. I'll be working on getting this released, next. Sorry, Corentin, for the delay. Fortunately I hadn't known in advance how much work I would have to put in to effect all these changes - if I did, I may not have had the heart to start them in the first place. Wed 04 Oct 2006 About Luca, and Tomorrow's Money, and TruthCategory : Commentary/tomorrowsmoney.txt I've finished (finally!) version 2.3 of Luca. I've made so many changes to the code that I'll need to do another few days of testing before I can release it. So, for the people who're looking to run Luca on 10.4.8, please wait - I'll have a version ready for you to run, hopefully, by the end of the week. I've made changes to Luca's data structure and so I've devised a way for people to update their database to the latest structure with maybe a couple of clicks. Most of the changes centre around making Luca handle multiple currencies more gracefully, so that it'll be able to handle differences in display formats and numerical precision and allow a user to specify these for individual currencies. So I was reading the following passage in the latest book by Alvin and Heidi Toffler - "Revolutionary Wealth" - with more than the usual interest : The basic unit of currency of money in America is the "almighty dollar". Few of those who use it every day know that until the industrialization of the nation was ramping up, the government-backed dollar was only one among as many as eight thousand different wildcat currencies in the United States issued by states, banks, individual companies, merchants and miners. The standardization of money imposed by the U.S. government in 1863 paralleled the standardization of products, prices and consumer tastes that came as part of the process of industrialization. And the same was true in other countries as well. The Japanese yen didn't become the national currency until 1871, as the Meiji restoration was starting the country on the path to industrial modernity. Similarly, the deutschemark did not become Germany's monetary unit until 1873, as Germany raced to overtake Britain as the leading industrial power. China long suffered from monetary chaos - with warloads, states, revolutionary bases, foreign enclaves and others each issuing their own currencies - right down to December 1948, as the communists took over and introduced the renminbi yuan. And Europe, of course, has only recently standardized on the euro. Ironically, this belated standardization - like much else in the European Union - comes just as the knowledge-based wealth system begins to move advanced ecoonomies in the opposite direction. In fact, homogeneous currencies are about to be challenged by a dizzying diversity of alternatives. Am I only solving yesterday's problem with Luca? Like a good sailor, we've got to keep one eye on the horizon no matter what else we're doing, lest we end up broken like the Titanic. Coming back to the Tofflers' book, it had somewhat mixed reviews on Amazon but I enjoyed it. Some books merely provide you with more of the same information, a few will deepen your understanding of a subject, but fewer still actually introduce new dimensions to think with. I enjoyed the book because I found new ways of looking at things. For example, what is truth? How do we know that something is true? Because a majority of people believe it to be so? Because we've always believed it to be so? Because a person in authority tells us it's so? Because it feels right metaphorically? Or because it can be proven right logically? It's interesting to do what the Tofflers did - list out the many ways in which we are led to believe that something is true. And see what remains valid now that we have so much information on tap, available so quickly, and that is so easily filtered and compared, debated and corroborated. As a boy from a Catholic family brought up by Protestant aunts and educated in Catholic schools, I used to wonder why nobody else I knew asked this question - who decided what books went into the Bible, as it was obvious (at least to me) that the Protestant and Catholic bibles were somewhat different? Now I have Elaine Pagels' "The Gnostic Gospels" on my bookshelf, and I've read as much about the Dead Sea Scrolls as I could find in the Libary, and I've just finished "The Lost Gospel of Judas". And I only have to search Google to know I'm not alone in wondering what really happened around the Sea of Galilee two thousand years ago and about the subsequent events that led to the founding of the Christian church. It's about deciding, after all is done and dusted, what's probably true and what's really a matter of faith - not nearly enough to justify a crusade or whatever names that has been known by - but Faith is about sincerity and I believe that's what really matters to God, if you believe He or She exists. So, to return to that constant theme of this weblog, "Man shapes his tools and in turn his tools shape Man". Technology is not neutral. So many chains of events are set off with the introduction of a really life-changing, life-defining technology. And we're living in such an age. It remains to be seen whether we're cursed or blessed to be living in these interesting times. Tue 03 Oct 2006 OS X 10.4.8Category : Technology/10dot4dot8.txt I've updated our own live server to OS X 10.4.8. The good news is that DNS, POP, IMAP, Fetchmail and Postfix services all continue to work OK in 10.4.8. However the "WorkAround-Bonjour" stall that Apple introduced with 10.4.7 is still there, unfixed. But the important thing is that all the services continue to work properly once you get past that (less than) one minute stall (when you enable a system service via a call to launchd - the "recommended way" that all applications are supposed to use when launching system services). Sun 24 Sep 2006 Perfection and SimplicityCategory : Commentary/perfection.txt If you had watched Stuart Cheshire's talk about Zero Configuration Networking with Bonjour on Google Video, you may have the caught the part where he talked about the importance of simplicity : "Any fool can make something complicated. And he followed that with a reference to a quote by Antoine de Saint-Exupéry: "In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away". I've had that quote playing on my mind the last two months working on Luca. It just so happened that I discovered an excellent book called "Let My People Go Surfing - The Education of a Reluctant Businessman - by Yvon Chouinard, founder of Patagonia, and what did I find but that quote again from Saint-Exupéry leaping off the 25th page : "Have you ever thought, not only about the airplane but whatever man builds, that all of man's industrial efforts, all his computations and calculations, all the nights spent working over draughts and blue-prints, invariably culminate in the production of a thing whose sole and guiding principle is the ultimate principle of simplicity?". "It is as if there were a natural law which ordained that to achieve this end, to refine the curve of a piece of furniture, or a ship's keel, or the fuselage of an airplane, until gradually it partakes of the elementary purity of the curve of the human breast or shoulder, there must be experimentation of several generations of craftsmen. In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away, when a body has been stripped down to its nakedness." - excerpt from Wind, Sand and Stars by Antoine de Saint-Exupéry. There you have it - art, science, sex, poetry, engineering, and simplicity. It all adds up to perfection. The JourneyCategory : Technology/journey.txt "It took me a long time to learn where he came from. The little prince, who asked me so many questions, never seemed to hear the ones I asked him. It was from words dropped by chance that, little by little, everything was revealed to me." It started with the question - do currencies always round to two significant digits, like US$9.99? The answer is no. There is at least one case, the Japanese Yen, e.g., ¥1,280 for a pack of Pampers, where they have no decimal places. So how do we make Luca work universally across all currencies without hard-coding all these things? The question started me on a journey of discovery where I learnt about NSDecimalNumbers, creating a custom NSNumberFormatter class in Cocoa together with its own Interface Builder palette, and also about storing blob values in SQL databases so I can stash these number formats that the user has created. And I'm now almost done. I have an interface in Luca that now allows a user to create custom number formats for any individual currency, and he can apply these formats wherever he's entering currency values in any voucher.
If he chooses the Japanese yen as the base currency for the accounting system in Luca, then all calculations where rounding has to be applied (e.g., in exchange rate or tax calculations) are done to zero decimal places. That's triggered in just one place in the code and there's no hard-coding. So, to answer my own question : it can be done. Along the way, I think, I can now really articulate why Cocoa and, especially, Objective-C are such good software development tools. It's all about design. You've got to take a Janus-like stance and look both inwards and outwards at the same time. You've got to look inwards into the code and be aware that the world you're modelling is as complicated as only life can be. And so, you've got to simplify, simplify, and simplify yet again wherever you can in the coding, to get everything neat, clean, crisp and small. Because if you don't don't, then you're going to get drowned in all the possible permutations when things come together in combination, when you meet a real user in the real world. It's from this perspective that we should value the simplicity of the Mac. And the wonderful pragmatism of the Objective-C language. And see how PC people like Paul Thurrott totally miss the point. And so I continue to simplify Luca. I'm pulling all Luca application settings into one single Preferences window, and I hope I can organise its presentation into a narrative to help the user understand what he has to do to set up an accounting system. If I can get this Prefs window done, then Luca will be reduced to just two menu items - an Accounts menu and a menu for Journal, and that would be about it. Sat 09 Sep 2006 SubversionCategory : Technology/subversion.txt I've made massive changes to, at least, the internals of Luca. I couldn't have done it without using Subversion, a version control system that I used to store my evolving Luca project files. There is a one-click install of Subversion for Mac OS X that you can get from Martin Ott's web site. I access my Subversion repository using this GUI front-end called svnX :
This combination of Subversion and svnX, together with FileMerge, below, which comes with Xcode, provides me with some sort of a Time Machine (no need to wait for Leopard). I'm able to compare across different versions of every file in my project, thus making it possible to do the kind of multiple changes that I was doing to a rather complicated project, in the last three weeks, in a very systematic way :
I'm highlighting this because I'm always puzzled why enterprises don't use Macs more. If they're worried about being locked in, a case can be easily made that they're even worse off, as far as being locked in is concerned, using Microsoft as their development platform. The tools I've mentioned, Subversion and svnX, are both free, open source projects. They're fast and work remarkably well. And they allow multiple programmers, spread out geographically, to work togther and synchronise their work with fine-grained precision. The databases I've been using, MySQL and SQLite, are also free and open source. In fact, in the last four years, I've totally turned over the things I know how to do. Prior to that, my main development platform was 4D (4th Dimension) and Oracle, and I used to pay $10,000 at least every two years for the privilege of using them. It slowly dawned on me, after OS X was released, that the economics of software development, at least on the Mac, was changing. I don't have to do those enterprise-scale systems I was doing anymore, to keep me in my fix, since I do enjoy building systems. But I was building systems for Windows users (although I stubbornly clung on to our PowerBooks) and that wasn't what turned me on each day. I wondered, then, if I could be doing the things I am doing now - selling the software I build over the Internet to Mac users, doing things on a smaller scale with, say, no more than three people, and spending more time with my kid. If this is any inspiration to others, I mean to say that if you can visualise something you want to achieve, you can often make it come true. But coming back to the topic, the tools we have at our disposal today are stupendous, absolutely first class. And most of them are free. Why is the enterprise not picking up on this opportunity? Systems are the life-blood any enterprise, whether you are a passion-driven company like Patagonia or a staid old company like (fill in the blanks). You need to be able to get at the data and shape your systems to meet your company's needs and its beliefs. Tools are the key. The best tools you can find. The simplest, easiest, strongest tools. Because building a company is hard. Why complicate things by using clumsy, overly elaborate, unfathomable systems like Windows? I like to think that the thing I'm doing now is subversive - to the current entrenched corporate wisdom. I'm using the best possible software development tool I can find, to build systems at the cheapest possible price, on a platform that nobody else had believed had a relevance to business, except for the Mac users, and to help make these Mac users successful in business. If I could ever be successful at it, that would be like proving a point. Fri 08 Sep 2006 Business, Computing, and the MacCategory : Technology/numberTest.txt I realised I hadn't written anything in three weeks. But I'm only now re-surfacing, having spent all that time inside the bowels of Luca, pulling out all references to doubles and floating point numbers, and replacing them with Cocoa's NSDecimalNumber class. Is it worth it? Consider the following code snippet : - (void)test:(id)sender So, we've got two numbers. One expressing 0.0001 as an NSDecimalNumber and the other as a floating point number. We loop around and add them up 10000 times. These are the results we get : [Luca 1397] total, as NSDecimalNumber = 1 With the NSDecimalNumber, we get the result we expected, 1. The floating point number, on the other hand, came very close to 1 but then, not quite. That's the problem we face working with floating point numbers. They really do float away from what they are meant to be. Let's see what havoc this causes in an accounting application. Let's say we're adding a long list of debits and credits. The two columns often won't balance, if we don't apply a mathematical function to round the figures. But then, when do you do the rounding? After the addition, or on each line item? And to how many decimal places? Two, if you're working with US dollars, none if we're working with the Japanese yen. The code easily becomes very complicated - unecessarily so because if the computer knew how to do its math, we wouldn't have to round at all. So that's what NSDecimalNumber does - it lets you work with greater precision so you get the result you want without having to go through all these contortions. That doesn't mean you eliminate rounding completely. You still have to apply a rounding function when you multiply, say, a monetary figure by an exchange rate, and you have to decide how many places you want to round it to (probably to the number of decimal places used by the currency you base your accounting system on). And you still have to work out how to handle dividing 1 dollar between 3 people, like who gets to keep the last cent. But at least we've cleared up, say 80% of the clutter in our code. So, imprecise calculation is one problem we faced in business computing that we can solve with that new data structure, called the NSDecimalNumber in Objective-C, and BigDecimal in Java. Then there's the problem of storage. Does the database system handle exact-number mathematics? Luckily, MySQL does, with its Decimal data type (since MySQL 5.0.3). So shuttling the data between Luca and MySQL is sweet - things go in and out the way you want. Not so with SQLite3. You get all this muck (in red, below) because SQLite still works only with floats and doubles and it can't represent a number like 513.58 exactly :
The problem comes when you read the data back. (Again, just when do you round the data, and to how many decimal places?) I'll have to attack this problem next. But let's move on. I keep mentioning that we need to figure out how many decimal places to round, say, an exchange rate calculation to, because it depends on the context. In the picture below, I show a Luca payment voucher where three currencies are involved. The original invoice was billed in Singapore dollars, and is being paid with Malaysian dollars. The base currency (the local currency used by our fictitious example company) is in US dollars and that's what we use to book the bank charges and the currency exchange gain under.
In this case, all three currencies are denoted to two decimal places. But if we get paid in Yen, we'd like, as Mac users, to see no decimal places at all when we're entering the Yen value. And when we print out that voucher we'd like to see the Yen symbol being printed, too. Fortunately, Cocoa has a user-interface class called the NSNumberFormatter class, that I have built a custom sub-class for, and that I can use inside Interface Builder, as if it were one of the supplied palette objects :
And the great thing about being able to use your own custom number formatter class is that it opens up a lot of possibilities. Suddenly, you're able to format numbers the way the French or the Swedes or the Indians want, and since you can get hold of your formatter object in your code during run-time, you can do a lot of currency formatting on the fly, or let the users customise it themselves.
If the user decides to format the Yen to no decimal places, you will be able to tell from the "Max fraction digits" parameter, above, and that's what you use to control the rounding behaviour. Plus you can set the rounding behaviour to say, the traditional way (which has a bias towards rounding up), or "bankers' rounding" where numbers are rounded down as often, statistically, as they are rounded up. And you can gather all these customisations in one logical place, so it's possible to avoid hard-coding anything in your application, and thereby making it all truly multi-currency. Cocoa is a wonderful development environment. Sometimes, like when I managed to get this working in Interface Builder, I was so excited and I wonder why don't more people see it? This is so great. Like, with the Spell Out Style, above, you can do cheque printing. And, though I haven't done it yet, you should be able to print it with fillers like asterisks between the currency symbol and the money value. Now, if all these are not doing things to support a business, then I wonder what is. And if the Mac is not a business machine, then what is? It took me three hours, from knowing nothing about Interface Builder palettes, to actually creating my own number formatter and getting it working in my own nib files. And I actually did this while parked near some people noisily playing mahjong in some relatives' house. I say this because I'm constantly amazed at how productive this development environment is. And yet how little people know about it in the mainstream. I was attending this talk by the CEO of Sybase, John Chen, yesterday (it was a very interesting talk - he shared his experience doing business in China - lots of interesting people pass through Singapore - I ought to be attending more of these). Anyway, I was talking to someone who found out that I'm working on the Mac, and he says, oh that's only a niche market, right? for the arty-farty types, right? Right. Fri 18 Aug 2006 BigDecimalsCategory : Technology/BigDecimals.txt This is very good tutorial, showing how BigDecimals are used in Java code : "Make cents with BigDecimal - Write Java programs to calculate and format currency". We can map all these calls to Objective-C in an equivalent way. Also, read this : "The Seven Habits of Highly Dysfunctional Design - In your face ! BigDecimal, BigInteger and BigMistake". Of Real Numbers, Floats, and DecimalsCategory : Technology/decimals.txt My last post about problems handling floating point numbers for financial calculations brought me a couple of responses. I make an assumption in Luca that all currencies work with two decimal places, and I round them wherever I can and store them to two decimal places. This way my accounts (should) always balance since, for every voucher, I make sure that the debits and credits are rounded to two decimal places and compared to be equal before I allow them to be saved. But what if I'm working with a currency that doesn't use two decimal places - they use three, or four, or five, or ... none? Guy Harris says - "Yes, the Japanese yen has no decimal places at all." That's just the motivation I need to go and dig further because the assumption I used wouldn't work if I want Luca to be used just about anywhere possible. Luca allows the base currency (the currency you use to base your accounting on and produce the financial statements) to be different from the billling currency and the settlement currency. So what if we get paid in Yen? Rounding the yen to two decimal places would make no sense at all. So what to do? I got one other mail from Quintin May that pointed me towards a whole new world of possibilities : "I read your post regarding floating point and rounding in Luca. It has been my experience when working with financial data to NEVER use floating point numbers. In Java, the BigDecimal type is preferred for this type of data representation. I'm not fluent in Objective-C, so I don't know if it has an equivalent data type. This article goes into excruciating detail on floating point arithmetic: http://docs.sun.com/source/806-3568/ncg_goldberg.html. Try a Google search for "objective-c" "bigdecimal". And that's what I did. Objective-C seems to have an equivalent class - the NSDecimalNumber. It has methods for adding, subtracting, multiplying, dividing, and comparing two objects of the same NSDecimalNumber type, plus conversion to formatted strings for display, with the correct separators and currency symbol, depending on locale. This looks like just what I need. Better still, new to MySQL 5.0, there's an equivalent exact-number data type called Decimal. So if all these pan out, a good strategy to take is : don't round, store all financial values as Decimal data types in MySQL, and load them into NSDecimalNumber data objects in Objective-C. Display them in windows and views as strings formatted according the appropriate locale, set according to whether the displayed value is in the billing, settlement or base currency. Do not add them like you would double or floating point numbers. Use the supplied methods, for addition, multiplication, and especially for comparison. So, this looks like a very neat idea. But will it all work out? And what about SQLite? It doesn't have an equivalent data type. There's only one way to find out - Just Do It ! I've often asked myself why I bother writing a weblog or why people would bother coming over to read it. Well, this is one benefit. I get responses. When I'm stuck, they point me to new, fortuitously more productive directions. And I hope you, dear reader, learn something useful also when I do. Read more ... |
Mac@Work
Services running on this server, a Mac Mini running Mac OS X 10.9.2 Mavericks:
all set up using MailServe, WebMon, DNS Enabler, DNS Agent, VPN Enabler, Liya and our SQL installers, all on Mavericks. |
||||||||||||||||||||||||||
