Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I get the sense that AppleScript is more respected than AutoIt. I think that it's something you can put on your resume whereas AutoIt is not. Is that the case? Why is that? With AutoIt you can automate just about anything. Is that the case with AppleScript? With AppleScript can you make it detect arbitrary images on the screen like images in a web page?
AutoIt had a big role in getting me my current job. If you get an interview with a team of developers, bringing something new to the table is not a bad thing. Sure you are not going to find "AutoIt Developer Needed" in the want ads, but more companies need one then know it. My use of AutoIt has turned into something that sets me apart from other developers in my work.
Picking the right tool for the job is what matters and for some jobs that tool is undoubtedly AutoIt. Most developers would be excited to see something they don't know on the resume of an applicant. It tells you several things.
This person is going to bring something unique to the team.
This person is into programming because they surely didn't learn AutoIt from a required class to get their degree.
Most people who love development are going to want to talk about this odd language you know that they have never heard of. If you have some example code that would be a pain in another language you have a good shot at impressing them.
It worked for me. While you are not likely to work full time as an AutoIt developer, I use it several times a week in my work.
Both languages serve very different purposes. They both started out with similar goals in mind, but evolved differently over the years.
AutoIt has adapted GUIs and has become more of a general purpose scripting language. It also has a large following of developers that all contribute to the functionality of the language. Applescript focuses mostly on what AutoIt was originally designed for, automation.
What really separates them on this focus is that AutoIt interacts based on commands and properties of Windows, where as Applescript interacts based on commands and properties of the application it is automating. Applescript is more similar to OOP, where as AutoIt is a traditional procedural language.
Why one is more popular than the other? that is a difficult question. I actually learned about AutoIt years before I knew anything about Applescript, but that is because I worked primarily on Windows and Linux machines and rarely on Macs. It really isn't a fair comparison to say one is more popular than the other, as there is no common element between them.
Windows users will know AutoIt, Mac users will know Applescript.
What exactly are you asking here?
AppleScript is likely more widely known than AutoIt (I never heard of AutoIt and just had to look it up). Whether that means it's more "respected" or "you can put it on your resume" is entirely subjective.
The two seem to be very different things. For what reason are you comparing/contrasting them? If you're looking for which one to use for any given purpose, the first important factor would be the platform. They're designed to run on very different platforms.
There may be some things you can do in one that you can not do (at least natively or without great difficulty) in the other. The same is true of just about any drastically different programming/scripting tools/environments.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Currently I am working on porting a benchmark application to another system. I am working alone, so I am frustrated about which software methodology I really have to use. Please give me some ideas.
I am going to assume you're wondering which Agile approach to use on your project as you tagged your question accordingly.
Agile is mainly about:
Delivering working software continuously and regularly
Aiming at technical excellence and avoiding technical debt
Improving the way we work and retrospecting regularly
I'd say whatever you use, even your very own approach to software development, if you can check those three items from the list, then you're pretty much Agile to me. Some people need strict guidelines and artifacts and that's fine, they help people become Agile but are far from being mandatory despite the dogmas out there.
Here's how I would approach your situation.
Take a step back and try to identify the most important features or abilities of this benchmarking application. By most important, I mean those features that the people using it in the end cannot live without. Once you have a list of those, put them on post-it notes, index cards, trello, jira or whatever tool you want to use.
Split each of those features into full-stack chunks of functionality that are business driven. I'm not talking about technical tasks here, but smaller features usable by actual people. I usually opt for the "Grandma Driven" approach here, asking myself "would grandma be able to understand what I'm trying to do?". It's just to make sure I'm focusing on a full stack feature and not a technical task like "populate database". One way to see this is also by applying dimensional planning to each of the features you identified (http://www.xpday.net/Xpday2007/session/DimensionalPlanning.html).
Set yourself an iteration length (I usually go for 1 or max 2 weeks when I'm working alone) and get to work one small item at a time. Don't write code for later, only what you need to solve the problem at hand. Quality is not an option. Focus on good coding and testing practices.
At the end of your iteration, check how many features you implemented and put that number somewhere on a chart, in a google spreadsheet or whatever. This will help you see if you're on track. Get feedback from colleagues or any potential users of the system and reflect on that feedback. It's not because you're porting to another platform that you can't make it better.
If you end up not having small enough granularity with what's left or not enough stuff in your list of things to do, spend some time repeating steps 1 to 3.
At the end of each iteration, keep tracking how many items you did just to see if you still have a good enough pace. If not, ask yourself why and change something in the way you work or get help. Again, your main focus is to make progress and deliver software that works at the end of each iteration.
It might not answer your question and I know I didn't give you an answer of the type, use kanban, scrum or whatever but I truly believe it's not appropriate in your specific case and would only generate overhead and boredom for you.
Hope that helps anyway, good luck with your project.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
I maintain Autoit project used for automated testing of swing app. Those tests have now about 70 files. It's get pretty hard to maintain all this code without following some "best practices" I'm trying to create as much functions as possible (because of duplicate code) and constants (frequent changes) bud it doesn't seem enough.
I have generally this types of functions:
Some general functions (insert text with logging, select or read from combobox.. )
Some screen specific functions (fill one form.. )
Some data/logic function - testing of app logic and data processing
Test case functions - combines previous 3 to implement some test scenario
AutoIt does not have classes => no inheritance => OOP principles are hard to aplicate ( :D clearly)
Does somebody have some experince with larger applications written in AutoIt? My opinion is, that AutoIt is for scripts < 500 lines and it wasn't good choice for this big project.
It's a shame, that AutoIt doesn't have some useful IDE.
AutoIt developers want to make sure that any functions written in AutoIt that are part of the core library (in short: UDFs) are subject to a certain code style. You can find this standard here: http://www.autoitscript.com/autoit3/udfs/UDF_Standards.htm Many programmers in the community write all AutoIt code in this standard.
On the subject of IDE. SciTE is a time-tested code editor, but as IDE it performs adequate. There are two other IDEs which are developed and maintained by the community:
A graphical debugger (F10 step next functionality) http://www.autoitscript.com/forum/topic/21834-graphical-autoit-debugger/
ISN AutoIt studio http://www.autoitscript.com/forum/topic/136766-isn-autoit-studio/
The last one is fairly new, but it looks extremely promising and it may work better for your project.
Finally, I have a note of warning. You say "OOP principles are hard to apply", but even as an OO programmer you should have a strong core idea of how to write non-OO code before you even learned OOP. Most OO languages are imperative at their core, so you should be an excellent imperative coder already. AutoIt is imperative as well.
A useful IDE will not solve your problems! But it will make them slightly easier to manage.
I don't know where you heard that AutoIt only performs well for scripts for under 500 lines, but every time you #include one of the default libraries you are adding ~10000 lines of code. If you can write proper code, you will build your own libraries without adding complexity to the rest of your code.
As AutoIt doesn't have (as you mentioned) the enabling characteristics of an OO language I think part of an answer here is to look at what AutoIt has and what paradigm best fits it. It's clear to me that AutoIt is a language meant to done using procedural programming methods. For me, it's actually a bit of fun to go back to those methods that way of thinking. My large programs end up, with an an emphasis on correctly defining computation modules, what is passed into the module (and returned). If you are severely missing OO benefits I think the next thing to focus on would be scoping -- trying to keep that as tight as possible.
As a final note, I think using the procedural programming techniques does usually end up creating a separate task of re-factoring after the functionality is up and running.
A place to start...but this was the dominant paradigm for decades
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I work on developer tools for a particular product. There is a competing set of tools for the same product produced by a different company. The user-base is split roughly 50-50 between us.
Recently, the other company has introduced scripting to make their own tools extensible by end-users. This is a feature that we have had planned for our tools for a while, but it is only now that we are able to start implementing it.
My question is: should we try as much as possible to collaborate with the developers of competing product so that end-user scripts can be shared between users on the different products? We would obviously require different implementations, but share the same syntax. This would obviously be better for the community as a whole since there would be more interoperability.
The downside of collaborating like this is that the competing product's scripting language is slightly tailored towards their own implementation. We would have to jump through a few hoops to create an implementation for their scripts on our platform. Or, we would have to somehow convince our competitor to modify their scripts so that they are platform agnostic.
So, to rephrase my question: should we try to collaborate, thus making our community happier, or should we produce a competing scripting language that is more appropriate for our platform?
I realize that this is a very general question with no single right or wrong answer. What I am looking for is a good explanation of the pros and cons of each approach.
I would write something that is specifically tailored towards my own system (don't compromise your technical quality) and then release and fully support a compatibility layer that allows my competitors scripts to run on my system (make it easy for users to migrate).
I'd stay away from doing things that will try to lock people in and cripple them if they move. These tactics worked once upon a time but in this day and age don't really cut it any more. I'd even go so far as to actually (unofficially on fora etc.) help people who are having trouble porting scripts running on my system to my competitors.
Another way to ask the question (and to answer) is to wonder WHAT KIND of script language is DESIRABLE FOR USERS.
If your competitor went a lock-in route with a proprietary scripted language, then please your users (and get a competitive edge) by using a STANDARD scripted language.
Doing so will immensely increase the value of your tool as many persons ALREADY know the scripted language.
Nobody wants to learn a new language.
Would building a unified scripting language harm your customer-base or give the competitor the competitive edge?
Obviously if you want to lock in customers, go solo which will prevent your customers from easily switching over to the competitor's product (sounds a little like Microsoft tactics) or if you know your product is superior, a collaboration will allow you to get customers from the competitor in which case customers will have the choice to choose which business model suits their needs, make a choice based on the quality of the product as a whole as well as which features they really need instead of being locked into an invisible contract due to the choice they made initially.
Going the collaboration route will also put your company in a position where developers will respect your company (for not being a greedy monopoly monster) instead of boycotting it due to their "moral" beliefs in open standards.
I would say that if possible make it compatible, not so much to cooperate but to compete. Making an incompatible solution would lock you customers in to some degree (you don't have any yet with a lot of scripts - so not much gain), but making a compatible solution keeps the door open for customers of your competition to migrate (they might have some scripts by the time you ship yours).
Just my 2cents
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In short I'm creating a 2D mmorpg and unlike my last "mmo" I started developing I want to make sure that this one will scale well and work well when I want to add new in-game features or modify existing ones.
With my last attempt with an avatar chat within the first few thousand lines of code and just getting basic features added into the game I seen my code quality lowering and my ability to add new features or modify old ones was getting lower too as I added more features in. It turned into one big mess that some how ran, lol.
This time I really need to buckle down and find a design that will allow me to create a game framework that will be easy to add and remove features (aka things like playing mini-games within my world or a mail system or buddy list or a new public area with interactive items).
I'm thinking that maybe a component based approach MIGHT be what I'm looking for but I'm really not sure. I have read documents on mmorpg design and 2d game engine architecture but nothing really explained a way of designing a game framework that will basically let me "plug-in" new features into the main game.
Hope someone understands what I mean, any help is appreciated.
If you search for component-based systems within games, you will find something quite different to what you are actually asking for. And how best to do this is far from agreed upon just yet, anyway. So I wouldn't recommend doing that. What you're really talking about is not really anything specific to games, never mind MMOs. It's just the ability to write maintainable code which allows for extension and improvements, which was a problem for business software long before games-as-a-service became so popular and important.
I'd say that addressing this problem comes primarily from two things. Firstly, you need a good specification and a resulting design that makes an attempt to understand future requirements, so that the systems you write now are more easily extended when you come to that. No plug-in architecture can work well without a good idea of what exactly you hope to be plugging in. I'm not saying you need to draw up a 100-page design doc, but at the very least you should be brainstorming your ideas and plans and looking for common ground there, so that when you're coding feature A, you are writing it with Future feature B in mind.
Secondly, you need good software engineering principles which mean that your code is easy to work with and use. eg. Read up on the SOLID principles, and take some time to understand why these 5 ideas are useful. Code that follows those rules is a lot easier to twist to whatever future needs you have.
There is a third way to improve your code, but which isn't going to help you just yet: experience. Your code gets better the more you write and the more you learn about coding. It's possible (well, likely) that with an MMO you are biting off a lot more than you can chew. Even teams of qualified professionals end up with unmaintainable messes of code when attempting projects of that magnitude, so it's no surprise that you would, too. But they have messes of code that they managed to see to completion, and often that's what it's about, not about stopping and redesigning whenever the going gets tough.
Yes, I got what you want...
Basically, you will have to use classic OOP design, the same one that business software coders use...
You will first have to lay out the basic engine, that engine should have a "module loader" or a common OOP-style interface, then you either code modules to be loaded (like, as .dlls) or you code directly within your source code, using that mentioned OOP-style interface, and NEVER, EVER allow a module to depend on each other...
The communication, even inside your code, should be ALWAYS using a interface, never put "public" vars in your modules and use it somewhere else, otherwise you will end with a awfull and messy code.
But if you do it properly, you can do some really cool stuff (I for example, changed the entire game library (API that access video, mouse, keyboard, audio...) of my game, in the middle of development... I just needed to recode one file, that was the one that made the interface between logic, and game library...)
What you're thinking about is exactly what this article describes. It's a lovely way to build games as I have blogged about, and the article is an excellent resource to get your started.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Should all team members be forced to use the same IDE (e.g. eclipse, netbeans, intellij) for programming, even though the build process is independent of IDE? (Assume no IDE specific plugins etc are being used on the project.)
If everyone is using the same IDE, they can share the same configuration and work in a more consistent environment. However, if you have been working with a certain IDE for many years, being forced to use another will be frustrating and reduce productivity because you will be trying to learn the IDE instead of focussing on the problem domain.
I am interested to hear which one of these two types of teams you have worked in and which one you think works best.
Thanks
If no specific plugins are being used then why not let people use what they want? We use a mixture of Eclipse, vim and other editors to edit a mix of Java, PL/SQL and Pro*C. We all have different vim setups, and it has never been a problem.
Having said that we all use Eclipse for Java, but that is mainly because it is the best IDE for Java (for our purposes).
We are all on different versions of it though so there is not really any enforced consistency there either.
I am a fan of letting each developer choose their IDE. I've worked in standardized environments and mixed, and I haven't seen much of a difference in productivity - its more of a morale issue (people forced to use tools they don't like are less happy).
You mention Java-centric IDEs (Eclipse, NetBeans, IntelliJ). In a Java-centric environment, one can use Maven to generate project files for those IDEs, which reduces a good portion of the argument for standardizing on a single IDE - because you standardize at a lower level - the Maven project file.
The only caveat to my opinion is that I find developers that choose to use simple text-editors rather than IDEs almost always create code that is riddled with warnings when viewed in an IDE, so I frown on that practice. Of course, if someone is a wiz with emacs or textmate, etc., and doesn't generate warnings, I have no problem with them continuing with their chosen platform.
I can not say much about Java. But as for C++, if you don't agree about indentation (is it spaces, tabs, tabs of what size) the code in runtime becomes a mess and less readable.
Additional point that can be against using several IDE in the same team if peer reviews/coding is done on regular basis (i.e. part of XP or coe review).
If these are not issues I don't see why team members can not pick up their favoirite IDE.
If you get too draconian about it you'll stifle innovation and in two years you will be on an ancient version of an IDE that is wholly inadequate for your task. On the other hand if you give free reign, each developer will do his own thing and you'll have a hit in productivity.
Have a "rule of 3". Let the team pick which IDE they want to use. If some members prefer a different IDE, allow for a second alternative. By the time that some members want to move to a third alternative it is only ok if the team agrees to get rid of one of the first two.
That way you have some consistency in your dev team (with the productivity gains that go with that) but you allow for moving to alternatives without a committee deciding it.
Forcing everyone to use the same IDE only works if you employ clones. Since every person is different, they have different approaches to solve tasks. If the gap becomes a too big, allowing individuals to use their preferred tool can boost performance and morale (morale because people feel better when they believe that they have an impact).
But that must not lead to a support issue. If someone is asking for some obscure IDE (for whatever reason), they better be able to solve their issues themselves. Choice doesn't mean you get an excuse to skip work because your tool breaks all the time.