Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I am going to be starting a new job soon and the company has previously had hobbyist developers working on their applications and as such not had to worry about supplying equipment for the developers.
Having spoken to them they seem to understand that I will need a reasonable system in order to ensure I am both as productive as possible and happy working there. I will be working both in there office and from home (about 50:50) so I need to ensure that I pick a setup which allows me to work comfortable from both.
One option I have is to use a dedicated workstation at the office with dual screens which I can use in the office. As I will be using SVN I could then work on my own systems at home so long as I make sure I check my code in every night.
Another option is for them to get me a new laptop which would be something like (dual core, 4gb ram, 1920x1200) and an external monitor so I can at least use 2 screens (even if they are not the same size)
Another option I am toying with right now, as I need to replace my old work laptop (I work freelance in addition to this job) is to finally make the move over to OS X and get myself a Mac Book Pro. Therefore my thought here would be to see if they are willing to buy a 27" iMac which I can use to run some VM's etc in along with other services (db, unit testing etc) and I can then use its monitor with the Macbook while at the office.
I could then take the work to and from the office and hook up the laptop to monitors at home and have a dedicated machine to run other intensive tasks.
I am hoping someone can help me decide which route would be best to try and recommend the company to go. In summary the options are:
A dedicated dual screen workstation
A dedicated work laptop and external monitor
A compromise with me supplying the laptop and them a desktop/monitor
In all 3 I would hope to still be able to edit and maintain code etc from home with code being in SVN. I think the main issues will be where email and documents go so I can have them on me all the time...maybe solved using Google apps or something
Thanks for any advice any of you might be able to provide.
You're going to want to continue to have a personal laptop. so make sure that you are the one owning the laptop no matter who pays for it. Given a choice, I'd rather own a laptop and use it part-time for business than use somebody else's laptop for my own purposes, commercial or personal, or juggle two laptops.
So, I'd ask for the best desktop development system I'd be likely to get, best being of course dependent on what you like, what you're doing, and company policy.
If you go for separate development machines at work and at home, you probably want a better system than trying to remember to check into Subversion at the end of each session. If you keep your version of the project on your laptop at all times, that would eliminate the problem. Other than that, if you could connect into your work machine from home, and your home machine from work, you could either use a distributed VCS (like Mercurial or Git) on your own machines or just log in to commit the stuff you forgot when you left last time.
Ideally, the monitors will have the same RGB pattern. Some monitors (e.g., Viewsonic 201b) have a "BGR" layout of the pixels on screen.
If you are using Windows with ClearType font rendering, it is important to have all monitors with the same pixel pattern -- otherwise the ClearType both looks funny, and causes a slowdown as you drag a window from one screen to the other.
I realize you might not use Windows, as you stated, but thought I would through this out to you. There could someday be similar issues with non-Windows OS. Also, I'm not sure if it matters for OSX at present, it might.
I have a MacBook Pro laptop and am very happy with it as a dev platform. It's a unix environment that has beautiful tools (I'm not looking at you, XCode) and is a pretty well built machine. The big advantage over using source control is that, even though SCM will allow you to work in different places (especially a distributed SCM like Git or Mercurial) the time will come when you will forget to push your changes - and if your workplace has any sort of security, going through firewalls, vpn, etc... is just a pain in the butt. I think it's much better to be able to carry your one configured machine with you.
Related
We have an S/390 mainframe at my new job that’s been running COBOL applications since the late 90’s. The mainframe is getting old enough that we need to migrate to a newer system. We’re a small enough business that we can’t warrant spending the money to upgrade to new mainframe hardware and the program logic has been a constant work in progress for 30+ years, so it has a lot of functional value. I’ve been considering moving the functionality to a Linux machine and using something like OpenCOBOL to recompile as an executable binary instead of trying to rewrite it in a newer language. I haven’t messed with a mainframe enough to have any clue how or where to access this information and the gentleman that wrote all of the programs is unfortunately no longer with us. I’ve read that SSH is an option, but I’m not even sure how to get the ball rolling on that with a mainframe. I use Linux on a fairly regular basis, so I’m familiar with SSH, but from my understanding those mainframes aren’t a simple OS that you can merely connect to and navigate the file system to retrieve data like we can in modern operating systems. Can anyone give me some pointers to get a sense of direction for accessing the source code for the COBOL programs? Are there default locations that they are stored, etc.? They’re somewhat simple programs that don’t use any DB2 functionality and will hopefully compile on a different system with relatively minimal debugging and fixes. I’m certain that I’ve left out necessary information that would help getting an answer to this question, and I can provide any additional information that is needed to help you all help me. I suspect that SSH isn’t enabled by default, but maybe I’m wrong there too. Any assistance is greatly appreciated. Thanks everyone!
Although not a programming question I'll provide some guidance I think might help you.
First, this is a business decision about where to invest.
Do we upgrade the system to a newer model and upgrade some software and acquire the skills to keep the system running? (System Programming, OS upgrade and cost of migration, newer platform (used z13 could be an economical option, storage systems to support the mainframe)
Migration of existing workloads to other platforms. (Cost to migrate code, sizing of performance needs, new technologies to replace existing access methods like VSAM or dare I say ISAM if the applications are old enough)
Status Quo ... leave things where they are and keep the lights on
In evaluating any option you have to assess the risk to the business and what would a disruption cost? IMHO, its less about a technology like SSH or COBOL on Linux but requires some serious assessment of the current state, the acceptable to be scenarios and the cost of pursuing one of those options.
My comments are not intended to instill fear but provide a framework of how do I approach analyzing a challenge of this magnitude.
There is no default location where source code is stored on z/OS (it is z/OS you're talking about, right?). Source code is usually stored in PDS data sets. The naming of those depends on the installation, i.e. the company, and whether or not any software like Endevor, ChangeMan, etc. is being used to maintain the sources.
Since this is old z/OS (OS/390) COBOL code, chances are the code is making use of OS specifics such as record level I/O, VSAM data sets, etc. These are the parts that will not work on a non-z/OS platform without major rewrite. So, you will need to look into the sources.
SSH is available on z/OS, but it needs to be configured and enabled. You need to check with your z/OS sysprog. FTP, and NFS are other options, but again, they need to be configured and enabled.
Transfering the sources is the least of your problems, I'd say.
I have to agree with the prior two answers, but have some additional suggestions. This is a business decision what to do on the system.
Finding the program to understand what it does is the first requirement. Since you know what program is running that may be the name of the source file. That you will need to find. The source file probably will be in some library manager, the first place to look is in the ISPF menu system. There will be an option for the library manager you are using if you are using one. Based on your description you may be using something called SCLM which would should up, or you might see Librarian or Panvalet. You will need to get into ISPF by connecting using a 3270 connection emulator. Once you find the file, using FTP or SFTP may be the best, or your emulator may just provide a transfer mechanism. You will need to find the related files as well, which should also be defined in the library manager.
Once you have the file, you will need to figure out what it uses as mentioned above, it will be working with some kind of data file, and that will be the biggest part to deal with.
If it is a batch program it is probably part of a schedule, and there are other programs also running that you will need to find and figure out how they fit together.
Once you have an understanding of all the parts then you can work to make the right business decision as to how this should be run. You may want to upgrade, you may want to look to getting z/OS as a cloud service if you don't want to upgrade but you want the function. Or it may be a simple program you could move. That will be much easier to figure out once you have the details.
You say the program logic has changing for 30+ years. Was it only one person making all the changes ? Would anyone on the team have some idea about the PDS's that the user had access to ? That might be one of the places to look for. As the previous answers suggested , most shops would have store the source code in some kind of config mgmt tool like SCLM or panvelet. If you have access to the load code, there are utilities that can be used to inspect the load member to get a CSECT listing which would have the names of the obj members that make up that load.You can check with your mainframe admins. That can get you the source code file names. We use SSH from USS in our shop to move code from a HFS folder to gitlab. I have also used plain FTP to just transfer source code files to my workstation . But yes, first you have to find where it is stored.
I apologize in advance. I'm almost certain this question may not be appropriate here, but there doesn't seem to be a specific place on SO for such questions, so I've decided that as a last ditch effort, I'll ask on the main site. Please don't be (too) angry with me....
I'm looking for a specific IoT project, that was developing modules connected by BLE. They were independent modules, say just a speaker, on a coin-sized die connected to each other or a computer via BLE. The project seems to have been succesfully funded on Kickstarter, with an SDK and shipping to the backers, but I can't find them again. I've been searching for a day and a half, but I can't remember for the life of me what they're called. I've searched through my chrome bookmarks, but the computer I was using at the time was a lab system, so I most likely wasn't logged into Google, and those systems are wiped every week. The project was probably from 2014, and they kinda advertised themselves as an easy way to learn HW/SW, and the SDK might have had Code block drag and drop, like Scratch. No combination of search terms that I can think of on Google is bringing up the results I want. Please help, if you know this project, or a specific way to find it.
I'm fairly certain this question will get moved, but before it does, I hope SO's vast and vastly informed community will be able to help me or point me in the right direction....
After days of searching and going through possibly most of the IoT style projects out there, I finally found the one I was looking for: it's SAM Labs. If anyone wants to know, it's probably one of the cheaper options for creating a limited use remote application.
I want to provide multi-monitor support in my application.
In the past I have had the simplistic view that multi-monitor support is simply the lack of open multi-monitor related bugs. If it seems to work on a multi-monitor setup, then it supports multi-monitors, right?
But I would like to create some clear requirements about this.
What are the basic requirements I need to adhere to, in order to satisfy most users' expectations so that they might say "yes this application supports multi-monitors"?
For example an obvious requirement is that all windows/messageboxes/tooltips etc must open on the same monitor that the application is on. And any children of those windows must open on the same monitor as their parent.
Can you think of any more? Are there any guidelines about this anywhere?
if the application was last used in a multi-monitor setup, and started up a second time with none of the additional monitors plugged in, make your application sense this and more all boxes and working areas back into the main screen.
(Eclipse doesn't do this and it annoys the hell out of me)
What makes me very happy is an application that remembers where all of its windows are (be they on the main monitor or second monitor) and re-displays everything in the same layout when I start up the application.
Couple of nasties to watch out for from personal experience (with GDI and Direct3D9 anyway):
When the two monitors have different bit depths, and the user expands the window to cover both monitors or drags it from one to the other... well it can get ugly if your app wasn't expecting it. Used to be much more of a headache back when systems might mix 8-bit palletized displays with higher bit-depth RGB ones (although be aware that such configurations are still out there for certain specialized applications).
Direct3D windows created on one "D3D device" may need attention if you drag them to another display (wholly or partially). Depending how you set up the device, windows either displays nothing on the other display, or does display content but with a massive amount of CPU-processing overhead (enough to kill high frame rates). (This was true on XP anyway).
I always thought this was an OS responsibility. It seems that way on the Mac. Alas, I've run into lots of apps in Windows that don't behave very well on dual monitors, though I've tended to blame that on the video card.
My biggest complaint are apps that insist on using an MDI interface only. MDIs are great if you have limited screen space but get quite annoying when you actually have lots of screen space and want floated pallets/documents separate from each other.
OK, not that kind of hostile. I'm curious to hear how people deal with developing on big corporate networks that mandate all kinds of developer-unfriendly services and policies on desktops (think ProQuota, over-zealous virus scanners, no local admin, no access to SO). I've previously used virtual LANs used effectively, or completely seperated parallel networks, but these aren't always practical. Any other tips?
The most important thing (if possible) is to recruit support from your boss.
Unless he's a PHB, he will often understand the impact of these restrictions on you, your team, and indirectly on his success. If the requests are reasonable, he can provide the buffer if you do go against IT. In addition, if the entire team or other developers seek the same policies, this "group bargaining power" can be used to create special policies.
Generally speaking, large corporations are over-zealous about legal issues and information security. However, IT departments generally hate dealing with numerous requests for support from the same person. Sometimes, if you show a clear harm to productivity from a project (e.g., you use a lot of temp files and the anti virus hits them), or that your program has to be installable from administrator mode, they will sometimes reach a compromise. You may have to sign something stating you would not use an administrative access on your machine to install illegal software, but you'd still get admin.
In the few cases I have gone for job interviews (I'm mostly in academia but worked some in the industry), one of my greatest concerns was the amount of control I had about my computing environment, from hardware, to software, to administrative rights. If I cannot be trusted as a developer to manage my own windows box, I don't feel I should be trusted with a mission-critical system.
I haven't tried this myself, but I once saw someone say that the central IT gave in and let him administer his own workstation, after he complied with the policies by submitting to them a change request form with a list of the first 300 things he wanted changing on his workstation.
Anything that interferes with you doing your job is good to bring up in a meetings.
Ex:
This Virus Scanner runs 4 times a day while I am at work. During that run my compile times take 5 times as long, and the use of my other development tools is brought down to a crawl.
The web filters are overzealous. I have attempted to access sites x, y, and z for extra development information, and have been unable. The time it took to find a good resources was doubled because of this.
And so on.
Work within the (hostile) rules and give up, quit and find somewhere more enlightened or try to change the organization, your choice.
If you decide to try and change things don't go against IT alone, that will just make you the "trouble maker" and you will never get anywhere, try to get support from your boss and other developers - if you can't get support then you may be better off looking for a new job.
I would explain your issues to your boss and/or sys admin, if they are receptive and agree its a good idea to let you have control over your workstation(s) then problem solved, if not I would walk from the project/job before your probationary period is over.
I was in a similar situation once at a large goverment corporation and it turned out management not be willing to unlock developers boxes was just the tip of the iceburg of a massive buracracy, the project ended up being a huge failure and by the time I left half of the IT department (not just the project team) had quit.
Just my 2 cents
Yeah. Leave. If your organization is not willing to give you the normal tools that any normal professional programmer should be able to use, then it's time to up your networking skills and update your resume.
Bringing your own laptop with the necessary tools is always a good way to overcome these man-made hurdles
Bring you own laptop but DON'T connect it to the network (and make it obvious that you do not intend to).
Copy stuff e.g. Visio diagrams over via USB drive.
If they don't allow USB, you can access the internat from outside and email the files. Using OWA via browser sometimes gives you more rights to send files.
Sounds like they're doing you a favor. Your code is guaranteed to run as a normal user, doesn't try to write to program files or other sensitive directories, is aware of what issues virus scanners bring to the table, and can handle other issues you wouldn't have normally encountered until installing your apps on a client machine.
As for no access to SO, I'd quit.
Our workplace required a full virus scan every day, so in the morning, when I hooked my laptop up, it was a 2 hour wait before I could do work.
I finally found a solution. MSVC 6, has a built in debugger. I went into task manager, and picked the mcaffee scanner process, and told it to debug. This fired up msvc6, and the scanner froze at a breakpoint. I hit reset, and the problem was gone. About 6 months later they removed the policy and all was good.
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 7 years ago.
Improve this question
Has anybody any successful remarks about having a team working via Remote Desktop?
In many workplaces, we put end users via Citrix and the applications on a central, powerful server. Sometimes the clients are in the same building as the server, but often, they are remote.
There could be some huge benefits for me to put my developers on Windows XP or Vista instances running on a couple servers with Hyper-V.
I'm worried that RDP/RDC via the internet would be too slow for somebody to be able to develop efficiently.
I'm sure I can hear plenty of bad things about it... are there any people out there that have had success?
I have seen a situation where the attempt was made to do this with a sattelite office. It was done for a java development team using various java IDE tools. The result wasn't regarded as a success, and the company brought the team back into a central London office at considerable expense.
For someone doing this on a day-in day-out basis on interactive software, the result isn't really very pleasant. For something that mainly uses text-based tools such as vim and unix command line tools, it works somewhat better. At one point I had XVNC going over a 128 Kbit DSL link (of a type that was prevalent in New Zealand at the time) and could do work on an Oracle-based data warehouse at a remote location quite readily. The level of interactivity required by the tooling made them much less sensitive to the slow link than a Windows-based IDE.
So, I'll invoke the 'it depends' argument with some qualifications:
I would not recommend it for a modern IDE, and certainly not for something heavily graphical like Dreamweaver, BI Development Studio or Informatica.
For a textual environment like traditional unix development tools it could probably be made to work quite well. These user interfaces are much less sensitive to latency than a direct-manipulation user interface.
I'm something of a believer in the 'best tools' principle. Going out of your way to give a second-rate user interface to a development team will give off negative signals. The cost saving from doing this is likely to be minimal and it will annoy some of your team members. Even if it can be made to work reasonably well you are still making a value statement by doing this. Weigh the cost saving against the cost of replacing one or more of your key development staff.
We connect to our development environments using RDP and locally the performance is great. It slows a bit over VPN, but is still acceptably responsive.
Turn off all the windows animation functionality, desktop background, etc. and that will help considerably.
If you're not worried about the latency on audio and fast-moving imagery and you're not developing anything dependent on 3D hardware, you'll likely be fine.
I've never used it in a team environment, but I use my laptop RDP'd into my workstation all day and love it.
I've worked in an environment where we would occasionally edit some existing code via remote desktop. There were no significant challenges to this. As a developer I positively hated doing that work. Everything felt slow and unresponsive. However, we got the work done.
Thankfully these were often short 3-4 hours jobs... mostly fixes to existing systems on remote customer sites. I don't think I could recommend it as a normal way of doing work, but its certainly possible.
I've used both VNC and RDP over a DSL connection, running through an SSH tunnel, and have had no real issues.
There are definitely some lags, particularly if you're redrawing large parts of a screen. But most development involves small edits, and both of these protocols handle that very well.
I use Remote Desktop to control my Windows machine at work. I use a Parallels VM on a Mac and my connection is 2.5M down, 256k up.
This works really really well. I've been doing this for 2 years for 1-3 days a week. The slow upspeed isn't an issue - I can't type that fast.
I have 3 screens at work but still find a 20" Mac screen to be superior. The colours are much cleaner and I can work longer at the Mac than my work screens!
The thing that is a killer is Flash on a browser. If I accidentally open a browser on my remote machine with Flash it kills the connection. The solution is to use FlashBlock (a firefox addin).
I use Eclipse and Visual Studio with no issues whatsoever.
I've used it to work from home (remote login to my in-office PC via VPN).
The performance depends on your ISPs, of course.
It's slightly less reliable (because as well as your having downtime when/if ever the office LAN is down, there's now additional risk of downtime while either of the internet connections is down).
I have a remote server on a 1Mbps upstream pipe which I RDP to (over a VPN) and it works just fine. I even use large screen resolutions (1600x1200) with no performance problems. Of course, I'm not sure how such a setup would fare for multiple concurrent users, however.
A benefit of developing over RDP that I hadn't anticipated is that you can save your sessions--so after you get done developing for the day, you quit your RDP client and power down your computer, and when you log back in the following day your session is right where you left it.
As an added bonus, RDP clients are available for linux, and OS X.
I use RDP daily for development, I leave my laptop on at home with my work environment open and ready to go. When I get to work and everybody is loading up their projects and opening their programs I just RDP in and I'm ready to go. You have to keep in mind certain keyboard shortcuts that change though (CTRL+ALT+DEL for example), it is annoying at first but you get used to it.
To keep the latency to a minimum, I recommend...
turning the colors down to 256 (after all, you only need to see text)
Leave the wallpaper at the other computer
Leave sounds at the other computer
Leave any themes on the other computer
Choose a lower connection speed, even if yours is higher. Windows will minimize the data sent.
One of the advantages you might also consider is processing power. If your machine at home has far better specifications than your workstation on the job, compilation time is improved a fair bit. Since your local machine only needs to update the image from the remote machine, your local computer is not under load.
Using this option also allows me to keep on track. While others log in and browse the internet and waste time, I'm set up and ready to go. Being more productive helps you get paid the big bucks (if your employer notices), while others are still stuck in their junior programming roles.
Pre-2000 I did it for 3 years every day several hours a day. This was when bandwidth sucked too.
Nowadays it's much much better.
And if you use NxMachine life gets even better :)
I did not, however, use the machine with multiple users. My concern with that would be that developers are a finicky bunch (myself included) and we tend to push machines really hard as it is.
Can't imagine several folks on one box all deciding to compile :)
G-Man
We do it with citrix and is very fast.
I wonder what the reason for this would be. Does the central server(s) have access to some resources that the individual developer machines could not access?
I'm using RDP to connect from my home computer to my work computer from time to time. I have to say - it's possible to code, but it's way more comfortable to do it when the IDE is on your own machine. Even when on a 100MBit LAN there is some noticeable lag. Not enough to bother work, but annoying nevertheless.
If the people have to work from remote places on a regular basis, I'd rather prefer a setup where the central source control is available through some secure protocol (HTTPS, VPN, etc.), but the development can happen locally on the developer's machines. If using something like SVN, which works well even with offline development, then it should be way more comfortable for the programmers themselves.
What is important for a development workstation is sheer processing power. At our place the developers have the most high-end workstations in terms of cpu, memory, disk, etc and not in terms of audio and graphics. It's the latter that are most affected by RDP.
As long as the server that your developers are RDP-ing to is fast enough to handle multiple compiles, builds at the same time you should be fine.
As with all things, the answer to your question is "Your Milage May Vary" or YMMV. It depends on what the developers are doing. Do they spend most of their time writing code, or do they do a lot of large compiles? Do they need direct hardware access?
Do they need debugging rights? Once you grant them debugging rights, they basically own the machine and can interfere with other users.
It's typically much better to allow the users to develop on their own computers, and use a VPN to allow them to acces the version control system. Then they can checkout the files to their local computers and do whatever they want, then checkin the changes.
But, RDP has it's advantages too. You really need to weigh the pro's and cons and decide which list is longer or more "weighty".
I use NoMachine NX Client to remote desktop onto a headless server that runs FreeNX. It is great because I can login to my session from anywhere and my last session is still there for me. Speed has never been a problem, except when the DSL line is down.
Anyway, my point is that if you are running a Linux server and use 'vi' then there is a nicer alternative than 'screen'.